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[57] ABSTRACT 

Abroadcast transmission system transmits data packets from 
a server to a client over a unidirectional broadcast network. 
The system transmits both full-length data packets, which 
have uncompressed headers, and reduced-length data 
packets, which have compressed headers derived from asso- 
ciated Tincompressed headers. The server compresses the 
data packets by compressing the packet header. Compressed 
packet headers contain fewer header fields than their asso- 
ciated uncompressed headers. The server transmits a series 
of intermixed full-length and reduced-length packets to the 
client. As the packets are received, the client determines 
whether the packets are full-length or reduced-length. If the 
packet is full-length, the client stores the uncompressed 
header in a header table. If the packet is reduced-length, the 
client rebuilds the compressed header from its correspond- 
ing uncompressed headers in the header table. 

42 Claims, 5 Drawing Sheets 
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DATA PACKET HEADER COMPRESSION 
FOR UNIDIRECTIONAL TRANSMISSION 

TECHNICAL HELD 

This invention relates to a broadcast transmission system 
in which data packets are sent over a broadcast medium to 
multiple clients. More particularly, this invention relates to 
a system and method for compressing headers in the data 
packets and delivering the compressed packets over the 
broadcast medium. 

BACKGROUND OF THE INVENTION 

Conventional computer networks are bi-directional, 
allowing data commimication in both directions between 
servers and clients. Transmitting data over these 
bi-directional data networks has been a mainstay of com- 
puter technology for many years and the communication 
protocols are well established. Under conventional commu- 
nication protocols, it is common for the client to initiate 
connection with the server and to request desired data from 
the server. As part of the request, the client sends informa- 
tion pertaining to how the data should be sent. For example, 
the client might include a client address, TCP port number, 
and so forth. 

Digital data, whether transmitted over a wire-based dis- 
tribution network (e.g., local area network, wide area 
network, cable, etc.) or a wireless distribution network (e.g., 
satelhte, RF, paging, etc.), is typically packetized and sent 
over the network in individual packets. Some protocols call 
for fixed size packets, while other protocols utilize variable 
size packets. To improve transmission efficiency and to keep 
pace with the exploding demand for digital information, 
there is a constant design objective to pump increasingly 
more data through the same bandwidth pipeline over the 
network. 

One way to achieve this objective is through packet 
compression. Packets are compressed at the server, trans- 
mitted in their compressed state over the network, and 
decompressed at the client. Apart from compressing whole 
packets, another solution is partial packet compression in 
which portions of the packet, such as a header or a data 
payload, are compressed. One technique for compressing 
packet headers is discussed in an article by V. Jacobson, 
entitled "Compressing TCP/IP Headers for Low-Speed 
Serial Links," and found at the web site http:// 
ds.intemic.net/rfc/rfcll44.txt. The Jacobson technique pro- 
vides an elaborate and complex compression scheme that 
reduces a 40-byte TCP/IP (Transmission Control Protocol/ 
Internet Protocol) packet header to a three-byte compressed 
header. The compressed header has an encoded change to 
the packet ID, a TCP checksum, a connection number, and 
a change mask. The hardware and/or software used to 
implement the Jacobson technique must perform sophisti- 
cated computations that compress the 40-byte header to the 
three-byte compressed header, and then subsequently 
decompress the compressed header to reproduce the uncom- 
pressed header. 

Apart from the classic bi-directional data networks, there 
is an increasing interest in the use of broadcast or multicast 
networks to deliver computer data and other content to 
clients. These types of distribution networks are unidirec- 
tional. Data flows from the server to the clients, but no return 
communication is possible over the same communication 
path. As a result, a unidirectional broadcast network cannot 
support the common protocols used for two-way commu- 
nication over a bi-directional network, such as chent-driven 
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connections and data requests, because the clients are unable 
to communicate over the broadcast communication link to 
the server. 

Like the bi-directional networks, there is benefit in send- 
5 ing compressed data packets over unidirectional broadcast 
networks. This invention is directed to a packet header 
compression technique that improves upon the Jacobson 
compression scheme, and that is specifically tailored for 
unidirectional broadcasts. 

ao 

SUMMARY OF THE INVENTION 

This invention concerns a broadcast transmission system 
for transmitting data packets from a server to a client over 
a unidirectional broadcast network. The system facilitates 
transmission of both fiiUzlength data pac kets, which have 
unc ompressed heade rs, and reduced^eng th data packets , 
wEich have compressed headers derived from associated 
uncompressed~Eea3erir 

2^ In general, the server compresses the data packets by 
compressing the packet header. Compressed packet headers 
contain fewer header fields than the uncompressed headers. 
ThQ server transmits a series of intermixed fi jil -leng th and 
r educed-len gth parVe-t<:_fW£j: the broadcast medium to the 
cHents. When a full-length packet is received, th e client 
s tores the uncompressed header in a header table . When a 
reduced-length packet is received, the client rebmlds the 
compressed header from the associated uncompressed 
header in the table from which the compressed header was 
originally derived. The uncompressed header is then 1 
appended to its data payload to effectively decompress the \ 
reduced-length data packet. 

According to one implementation, the server has a packet 
header compressor to compress an uncompressed header 

35 into a compressed header. The uncompressed header has 
multiple fields. As an example, a UDP/IP (User Datagram 
Protocol/Internet Protocol) packet header has several well- 
defined IP fields — such as a version field, a header length 
field, a type of service field, a total length field, a packet 
identification field, a flag field, a fragment field, a time to 
live field, a protocol field, a header checksum field, a source 
IP address field, and a destination IP address field — and 
several well-defined UDP fields — such as a soxurce port 
number field, a destination port number field, a UDP length 

45 field, and a UDP checksum field. Some of these fields do not 
change from packet to packet, rather only a subset of the 
fields changes. 

The packet header compressor forms a compressed header 
from the fields of an associated uncompressed header. The . 

50 compressed hea der contains one or more fields, w hich-aiP 
s ubject to change irom packet-to-pack et, but not aU of the 
fields in a normal uncompressed header. The fields that are 
common to both the compressed and uncompressed headers 
are otherwise identical. Compression is achieved by remov- 

55 ing the non-changing header fields from the compressed 
header. For instance, in the case of compressing a UDP/IP 
header, the packet header compressor might form a com- 
pressed header having only the packet identification field, 
the flag field, and the fragment field, which change from 

60 packet tp p^ket, while omitting the other IP and UDP fields. 
The server also has a packet encoder to construct fuU^ 
length and reduced- length data packets by appending data ^ 
payloads an d compression key blocks to ^e uncompressed_> 
an d compressed hea ders? A fiill-length data packet includes 

65 a compression key block, an uncompressed header, and a 
data payload. A reduced-length data packet includes a com- 
pression key block, a compressed header, and a data pay- 
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load. The compre ssion key block has a com gressionJat 
value thafjScntifies the packet as either a full-length data 
packet or a reduc^-lcngth jiata packet. Th_e_compression 
key bloclT alsocoptaips a header index value that indexes to^ 
a mcmoiy location in a header table at a recipient where the ' 
uncomp r essed packet header i s or will be sto red. A trans- 
mitter resident at tie server transmits the full-length and 
reduced-length data packets over a unidirectional distribu- 
tion medium to the clients. 

Each client has a packet decoder to extract the compre^ - 
sion keyj2locks from the data packets. If the compression bit 
value indicates that the packet is full-length, the packet 
decoder stores the uncompressed header in the memory 
location of the header table referenced by the corresponding 
header index value. On the other hand, if the compression bit 
value indicates that the packet is reduced-length, the client 
utihzes a packet header decompressor to reconstruct the 
uncompressed header. The packet header decompressor 
accesses the header table at a memory location indexed by 
the header index value contained in the reduced-length data 
packet. The memory location holds the uncompressed 
header from which the compressed header was derived. The 
packet header decompressor then reconstructs missing fields 
in the compressed header from the full set of fields in the 
associated uncompressed header. The full-length packets 
and decompressed packets are then passed onto the next 
layer in the protocol stack for further processing. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a diagrammatic illustration of a broadcast 
transmission system for broadcasting data packets firom a 
server to multiple clients over a unidirectional broadcast 
medium. 

FIG. 2 is a functional block diagram of a packet com- 
pressor located at the server to prepare data packets prior to 
transmission over the broadcast medium. 

FIG. 3 is a diagrammatic illustration of a header con- 
structed according to UDP/IP (User Datagram Protocol/ 
Internet Protocol) format. 

FIG. 4 is a diagrammatic illustration of a data structure for 
a full-length data packet type. 

FIG. 5 is a diagrammatic illustration of a data structure for 
a reduced-length data packet type. 

FIG. 6 is a block diagram of the client. 

FIG. 7 is a diagrammatic illustration of a series of 
intermixed full-length and reduced length data packets and 
a header index table, 

FIG. 8 is a flow diagram of a method for serving full- 
length and reduced-length data packets from a server to a 
client over a broadcast medium. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

FIG. 1 shows a broadcast transmission system 20. Content 
is delivered in the form of data packets a broadcast server 22 
over a broadcast medium 24 to multiple clients 26(1), 26(2), 
. . . , 26(N). Examples of transmittable content include 
computer data, audio, video, animation, bit maps or other 
graphics, applications or other executable code, text, 
hypermedia, or other multimedia types. 

The broadcast medium 24 may comprise the entire dis- 
tribution network between the server and client, or it may be 
a single link in a larger distribution network. Generally, the 
broadcast medium 24 is unidirectional in the sense that 
packets are delivered from the server 22 to the clients 
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26(1)-26(N) without requiring return communication from 
the clients. The broadcast medium 24 can be characterized 
as a shared, highly asymmetrical, network resource with a 
limited, if not completely absent, low speed return path that 
does not need to be active to receive broadcast transmis- 
sions. 

The broadcast medium 24 can be implemented in a 
variety of ways. For instance, the broadcast network might 
be implemented as a wireless network configured for one- 
way transmission (i.e., satellite, radio, microwave, etc.). The 
broadcast network might also be a network that supports 
two-way communication (i.e., Internet, LAN (local area 
network), and WAN (wide area network)), but can be used 
for unidirectional multicasting from the broadcast server 22 
to the clients 26(1)-26(N). 

In general, the server 22 and the client 26 both have 
knowledge of the protocol and the block format of each 
packet. The server 22 compresses certain ones of the data 
packets by compressing their packet headers. Compressed 
packet headers contain fewer header fields than the uncom- 
pressed headers. The server 22 transmits both full-length 
data packet headers (which contain uncompressed headers) 
and reduced-length data packets (which contain compressed 
headers derived from the uncompressed headers) over the 
broadcast medium 24 to the clients. To realize suflScient 
benefit, a higher percentage of compressed, reduced-length 
packets are transmitted in comparison to fiiU-length data 
packets. The client stores the uncompressed headers of the 
full-length data packets in a header table. The cMen tJthen.: 
rebuilds c omp ressed headers from the uncompressed head - 
ejs in t he table to decompress the reduced-length data 
packets^ <> 

FIG. 2 shows a packet compressor 30 implemented at the 
broadcast server 22. It includes a packet header compressor 
32, a packet encoder 34, and a header table map 36. The 
packet compressor 30 can be implemented in hardware, 
software, or a combination of both. One example imple- 
mentation is to incorporate the packet compressor into 
server software, such as Windows® NT from Microsoft 
Corporation, which executes on a server computer. 

Thejiac ket header compressor 32 receives an incoming^ 
stream of full -length data packets thaL-Comprisft a rjjata 
payioad and an uncompressed packet head er. The data 
packets may be constructed according tojang orjujiUj^tle, 
protocol forma ts. For discussion purposes, aspects of this 
invention are described in the context of a UDP/IP (User 
Datagram Protocol/Internet Protocol) format. However, this 
invention can accommodate other well-known formats^ as ^ 
weU, includinsJTGP/IP , IPX/SPX, and NetBEUI, Moreover, 
one aspect' ot this mvention concerns a header compression 
scheme that is capable of supporting multiple different 
formats individually or intermixed. 

FIG. 3 shows an uncompressed header 40 constructed "^^i^j 
according to the UDP/IP format. A 16-bit protocol block 42 I j 
identifies the protocol format for the header 40 . In this case, \ *^M\cvt 
Ihe protocol block 42 contams the protocol number n 
"OxOSOO'*, which specifies the UDP/IP protocol. The header J 
40 also has a 160-bit IP portion 44, and a 64-bit UDP portion 
46. The IP portion 44 consists of multiple IP fields: a 4-bit 
version field, a 4-bit header length field, an 8-bit type of 
service field, a 16-bit total length field, a 16-bit packet 
identification or sequence field, a 3 -bit flag field, a 13-bit 
fragment field, an 8-bit time to live field, an 8-bit protocol 
field, a 16-bit header checksum field, a 32-bit source IP 
address field, and a 32-bit destination IP address field. The 
UDP portion 46 consists of multiple UDP fields: a 16 -bit 
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source port number field, a 16-bit destination port number 
field, a 16-bit UDP length field, and a 16-bit UDP checksum 
field. 

Tlie fields in the IP and UDP portions are well known, and 
are not discussed in detail. A detailed discussion of the UDP 5 
and IP formats is provided in a number of textbooks, such as 
Richard Stevens, TCPjlP Illustrated, Volume 1, Addison- 
Wesley Publishing Company, (D1994 and Douglas E. Comer, 
TCP/IP, Volume I, Principles, Protocols, and Architecture, 
Third Edition, Prentice Hall, ©1995. lO 

Some of the fields in the packet headers do not change 
from packet to packet, rather onTy a subset of the fields 
changes. In the case of the UDP/IP format, only the 16-bit 
packet identification field, the 3-bit flag field, and the 13-bit 
fragment offset field change from packet to packet. Other 
fields might change every few or more packets, but not every 
packet. In addition, some fields are redundant or non- 
essential and can be omitted or recomputed on the client 
side. 

20 

With reference again to FIG. 2, the packet header com- 
presso r 32 forms a compressed header from the fields ofan 
associated uncompressed header. Preferably, the packet 
-header"ci5mpressor M torms a compressed hea der havi ng 
those fields that are subject to change fr om packet-to-packe t, 
butnot all of the fields in' a normal uncompressed header. In 
the UDP/IP example, the packet header compressor 32 
forms a 32-bit compressed header containing only the 16-bit 
packet identification field, the 3-bit flag field, and the 13-bit 
fragment offset field. The other IP and UDP fields arej^^ 
omitted. 

The fields that are common to both the compressed and 
uncompressed headers are identical That is, the fields them- 
selves are not compressed The 16-bit packet identification 
field, for example, is the same in both uncompressed headers 
and compressed headers. Compression is achieved by 
removing the non-changing header fields from the com- 
pressed header. In the UDP/IP case, the packet header is 
compressed from 224 bits to 32 bits. By keeping the fields 
the same, the header compression technique simpfifies 
packet header compression and decompression at the server 
and client. 

In FIG. 2, the packet encoder 34 receives the data pay- 
loads and packet headers (compressed or uincompressed) 
from the packet header compressor 32 and forms full-length 45 
and reduced-length data packets that are ready for transmis- 
sion over the broadcast m*edmm. Full-length data packets 
have a data payload and an uncompressed header, whereas 
reduced-length data packets have a data payload and a 
compressed header. Reduced-length data packets may also jq 
be referred to in this disclosiu-e as "compressed" data 
packets. 

FIG. 4 shows a fuU-length data packet 50 that is con- 
structed according to the UDP/IP format. The full-length 
data packet 50 includes an X-bit data payload 52 and an 55 
uncompressed.UDP/IP header 40. The uncompressed header 
40 consists of the 224-bit IP and UDP headers 44 and 46, and 
the 16-bit protocol block 42 (FIG. 3). 

FIG. 5 shows a compressed or reduced-length data packet 
60 that is derived from the full-length data packet 50. The 60 
reduced-length data packet 60 has the X-bit payload 52 and 
a compressed header 62. In the UDP/IP case, the compressed 
header 62 is a 32-bit header comprising the 16-bit packet 
identification field, the 3-bit flag field, and the 13 -bit frag- 
ment offset field. 65 

The packet encoder 34 (FIG. 2) appends a compression 
key 54 to each packet, regardless of whether the packet is 



fiill-length or reduced length. As shown in FIGS. 4 and 5, the 
compression key 54 has a compression bit value 56 and a 
header index value 58. The compression bit value 56 iden- 
tifies the packet as either a full-length data packet or a 
reduced-length data packet. In this example, the compres- 
sion bit value is a one-bit compression flag that is a first 
binary value, such as a "0*', when the data packet is 
full-length and a second binary value, such as a "1", when 
the data packet is reduced -length. 

The header index value 58 references a memory location 
at the destination client. More particularly, the header index 
value 58 is used to reference an entry in a header table at the 
destination client. If the header index value 58 belongs to the 
fiill-length data packet 50, the header index value designates 
an entry in the header table for storing the uncompressed 
header 40. On the other hand, if the header index value 58 
belongs to the reduced-length data packet 60, the header 
index value designates an entry in the header table that stores 
(or will store) the associated uncompressed header 40 from 
which the compressed header 62 is derived. 

With continuing reference to FIG. 2, the packet encoder 
34 derives one or more reduced-length data packets from a 
full-length data packet. A fiill-length data packet and a 
reduced-length data packet are said to be "associated", 
"corresponding" or other similar language if the compressed 
header in the reduced-length data packet is derived from the 
uncompressed header in the full -length data packet. 
Likewise, an uncompressed header and a compressed header 
are said to be "associated", "corresponding" or other similar 
language if the compressed header contains a subset of the 
fields found in the uncompressed header. 

The packet compressor 30 includes a header table map 36, 
which tracks or mirrors the entries in the header table at the 
client. When the packet encoder 34 assigns a header index 
value to a full-length data packet, the packet encoder 34 
requests from the header table map 36 an index value to a 
new location in the header table for storing the uncom- 
pressed header. When the packet encoder assigns a header 
index value to a reduced-length data packet, the packet 
encoder 34 receives from the header table map 36 an index 
value to a location in the header table that stores the 
associated uncompressed header. Through the use of the 
header table map, the server is in complete control of when 
an uncompressed header is sent, and where it is stored at the 
client. 

It is noted that the packet encoder 34 may append other 
headers and trailers to the data packets. For instance the 
packet encoder might add a trailer containing a CRC (cyclic 
redundancy check) value. The packet encoder prepares the 
packets for transmission over the broadcast medium. 

The packet compressor 30 outputs both the full-length and 
reduced-length data packets to a transmitter 38 for trans- 
mission over the broadcast medium. The transmitter 38 may 
be implemented in many different ways, depending upon the 
network implementation. For instance, the transmitter 38 
may be a satellite uplink, an RF transmitter, a microwave 
transmitter, a modem, a network card, and so forth. 

FIG. 6 shows an exemplary configuration of a client 26 
implemented as a broadcast -enabled computer. It includes a 
central processing unit having a processor 70 (e.g., x86 or 
Pentium®-family microprocessor from Intel Corporation) 
and memory 72. The memory 72 generally includes volatile 
memory (e.g., RAM) and non-volatile program memory 
(e.g., ROM, disk drive, floppy disk drive, CD-ROM, etc.). 
The cHent 26 typically has one or more input devices (e.g., 
keyboard, mouse, etc.) and a computer display (e.g., VGA, 
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SVGA), which are not shown in this figure. The client 26 that is stored in table entry 0. Accordingly, the packet header 

also includes a digital broadcast receiver 74 (e.g., satellite decompressor uses the index value of 0 to access the header 

dish receiver, RF receiver, microwave receiver, NTSC-VBI table 84 and locate the associated uncompressed header 

receiver, digital cable TV decoder, modem, network card, UH(0) for rebuilding the compressed header UH(0). This 
etc.) to receive the full-length and reduced-length data 5 process is continued for the next reduced-length packet 

packets from the distribution medium. 60(0,1), and so on. 

The client 26 runs an operating system 76 that supports The next full-length packet 50(1) has an index value of 

multiple applications. The operating system 76 is preferably "1" (i.e., the "I«l" block) which references entry 1 in the 

a multitasldng operating system that allows simultaneous header table 84. The packet decoder 80 stores the uncom- 
execution of multiple applications. One preferred operating lO pressed header UH(1) from data packet 50(1) at entry 1 in 

system is a Windows® brand operating system sold by the header table 84. Any reduced-length data packet 60(l,y) 

Microsoft Corporation, such as Windows® 95 or Windows® that is derived from full-length packet 50(1) also carries a 

NT or other derivative versions of Windows®. It is noted, header index value of 1 to locale the associated uncom- 

however, that other operating systems may be employed. pressed header UH(1). 

In the FIG. 6 implementation, the operating system 76 The header table 84 has additional space 90 to temporarily 

incorporates a packet decompressor 78 to decompress data cache compressed headers in the event that their associated 

packets received by the receiver 74 from the broadcast uncompressed headers are not yet received at the client and 

medium. The packet decompressor 78 has a packet decoder stored in the table. If a compressed header arrives at the 

80, a packet header decompressor 82, and a header table 84. chent before the uncompressed header from which it is 

Although the packet decompressor 78 is shown imple- derived, the compressed header is cached until the associ- 

mented in software as part of the operating system 76, it may ated uncompressed header is indexed into the table. In FIG. 

alternatively be implemented as a separate component in 7, the reduced-length data packet 60(1,0) is received prior to 

hardware and/or software. its corresponding full-length data packet 50(1). The packet 

The packet decoder 80 extracts the compression key 54 decoder 80 places the compressed header CH(1) in a com- 

from each incoming data packet. If the compression flag 56 pressed header cache 90. After the associated uncompressed 

in the compression key 54 indicates that the packet is header UH(1) is received and stored in entry 1, the packet 

full-length, the packet decoder stores the appended uncom- decompressor 82 retrieves the cached compressed header 

pressed header 40 in the header table 84 at a memory CH(1) from cache 90 and rebuilds it from the uncompressed 

location referenced by the header index value 58. If the header UH(1). 

compression flag 56 in the compression key 54 indicates that The header table 84 has a finite number of entries "M". 

the packet is reduced-length, the packet decoder passes the The uncompressed headers UH(0), UH(1), . . . UH(M-1) 

appended compressed header 62 and header index value 58 stored in the table can be configured to time out or expire 

to the packet header decompressor 82. after a preset duration. This ensures that only up-to-date 

It is noted that the packet decoder 80 may perform other uncompressed headers are maintained in the table. Since the 

functions, such as error analysis, stripping away carrier server is in complete control of when an uncompressed 

headers that are not needed by the upper layer protocols, and header is sent, and where it is stored in the table, the server 

the like. can send new uncompressed header entries as desired. 

The packet header decompressor 82 reconstructs an \ Additionally, the table 84 can be implemented to help 
uncompressed header from the compressed header received 40 manage the entries. For instance, the header table 84 may 

from the packet decoder 80. The packet header decompres- manage entries according to a first-in -first-out (FIFO) 

sor 82 utilizes the header index value 58 to reference the protocol, so that the newest header overwrites the oldest 

memory location in the header table 84 that stores the header. However, other protocols may be used, such as one 

associated uncompressed header. The decompressor 82 based on frequency of use whereby newly added headers 
rebuilds the header by adding the missing fields in the 45 overwrite the least frequently used headers, 
compressed headers from the fuU set of fields in the asso- One advantage of this compression scheme is that it is not 

ciated uncompressed headers store in the table. In the protocol dependent. The UDP/IP format is used herein as an 

UDP/IPcase, the packet header decompressor 82 adds all of example, but many other formats may be used. Moreover, 

the fields in the IP portion 44 and UDP portion 46, excepting the compTgssion scheme_xan^acconmiodatejsimultaneou§^ 
the packet identification field, the flag field, and the 5Q jtrayQsmjssipn^of different protoc^ so long as the client and i 

fragment/offset field from the IP portion 44 that are already server are both aware of the different types. In FIG. 7, for 

present in the uncompressed header. example, the first full-length data packet 50(0), and its 

FIG. 7 illustrates the packet decompressing process reduced-length derivatives 60(0,y), may be encoded using 

implemented at the client, A series of intermixed full-length one format and the second full-length data packet 50(1), and 
packets 50 and reduced-length packets 60 is received at the 55 its reduced-length derivatives 60(1, y), may employ a differ- 

client from the broadcast medium. The first full-length ent format. 

packet50(0)hasanindexvalueof"0'* (i.e., the "1=0" block) FIG. 8 shows exemplary steps in a method for serving 

which references entry 0 in the header table 84, The packet full-length and reduced-length data packets from a server to 

decoder 80 stores the uncompressed header UH(0) from data a client over a broadcast medium. At step 100, the server 22 * : , 
packet 50(0) at entry 0 in the header table 84, as indicated 60 compresses s elect packet hea^d ers. " gie server 22 can employ 

by the solid arrow. many c^fferent techniqucs^f 63£ho'5siri^ which p a g jcet head -^ 

The next packet in the series is a reduced-length packet ers^jp^compress. -f Unc approach is to identify groups of 

60(0,0). The notation "60(x,y)" means the reduced-size packets in which only-a-^predetermined-subset of fields | 

packet 60 that is derived from the x''' full-length data packet. change and for each group, leave one uncompressed header ] 
The reduced-length packet 60(0,0) carries an index value of 65 and compress the remaining headers from the uncompressed 

"0" (i.e., The "I»0" block) because the compressed header header. Another technique is to try to compress P headers for ^j,^^ 

CH(0) is associated with the uncompressed header UH(0) ^every uncompressed header, y .^^--^^ 
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At steps 102 and 104, the server 22 appends the data 
payload and compression key to the uncompressed or com- 
pressed header to form full-length or reduced-length data 
packets, respectively. The server 22 transmits a series of 
intermixed full-length and reduccd-length^data.p ackets ove r 
the broadcast meaium~2^'toThe^lients 26(1)-2^N) (step 
106 in FIG. 8). 

At step 108 in FIG. 8, each client 26 receives the packets 
and checks the compressiqn^ag in the compression key. If 
the flag is a binary "0" indicating that the packet is full- 
length (i.e., the "yes" branch from step 110), the client 26 
extracts the uncompressed header and stores it in the header 
table 84 at an entry indexed by the header index value (step 
112). Conversely, if the flag is a binary "1" indicating that 
the packet is reduced-length (i.e., the "no" branch from step 
110), the client 26 extracts the compressed header from the 
data packet (step 114) and uses the header index value to 
access the associated uncompressed header in the header 
table 84 (step 116 in FIG. 8). The client 26 uses the 
uncompressed header to reconstruct the compressed header 
(step 118). As the reduced-length packets are decompressed, 
the client passes all packets, including the decompressed and 
full-length packets, up to the next protocol layer in the 
protocol stack (step 120 in FIG. 8). 

Although the invention has been described in language 
specific to structural features and/or methodological steps, it 
is to be understood that the invention defined in the 
appended claims is not necessarily limited to the specific 
features or steps described. Rather, the specific features and 
steps are disclosed as preferred forms of implementing the 
claimed invention. 

We claim: 

1, A method for serving full-length and reduced-length 
data packets from a server to a client over a unidirectional 
broadcast medium, each full-length data packet having a 
data payload and an uncompressed header with multiple 
fields, the method comprising the following steps: 

at the server: 

compressing an imcompressed header to form an asso- 
ciated compressed header having a subset of one or 
more of the fields so that the fields that are common 
to the associated uncompressed and compressed 
headers are identical; 
forming a reduced-length data packet having the com- 
pressed header and a data payload; 
appending a compression key to each of the full-length 
and reduced-length data packets, the compression 
key specifying whether the appended data packet is 
full-length or reduced-length and whether the full- 
length and reduced-length data packets have associ- 
ated uncompressed and compressed headers; 
transmitting the fuU-length and reduced-length data pack- 
ets from the server to the client over a unidirectional 
broadcast medium; 
at the client: 

extracting the uncompressed header firom the full- 
length data packet; 

storing the uncompressed header; 

extracting the compressed header from the reduced- 
length data packet; and 

decompressing the compressed headers by adding 
fields from the uncompressed header stored at the 
cUent that is indicated by the compression keys as 
being associated to the compressed header, the added 
fields restoring the subset of fields contained in the 
compressed header to said multiple fields contained 
in the uncompressed header. 
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2. A method as recited in claim 1, wherein the appending 
step comprises the step of appending a two-block compres- 
sion key having a first block that specifies whether the 
appended data packet is full-length or reduced-length and a 

5 second block containing an index to a table at the client, 
whereby the associated uncompressed and compressed 
headers are indexed to a same location in the table. 

3. A method as recited in claim 2, wherein the storing step 
comprises the step of storing the uncompressed header in the 

jQ table, and further comprising the step of subsequently 
removing the uncompressed header from the table to make 
room for new uncompressed headers. 

4. A method as recited in claim 1, further comprising the 
step of temporarily caching the compressed header in an 

j5 event that the uncompressed header associated with the 
cached compressed header has not yet been received at the 
client. 

5. A method as recited in claim 1, further comprising the 
step of transmitting a higher percentage of the reduced- 

20 length data packets in comparison to the full-length data 
packets. 

6. A method as recited in claim 1, further comprising the 
step of forming and transmitting multiple groups of fuU- 
length and reduced-length data packets, wherein each said 

25 group of data packets is formatted according to a different 
transmission protocol. 

7. Computer-readable media located at the server and the 
client having computer-executable instructions for perform- 
ing the steps of the method as recited in claim 1, 

3Q 8. A reduced-length data packet having a compressed 
header embodied on a transmission medium and constructed 
according to the steps performed at the server in the method 
as recited in claim 1. 

9. A method for compressing a data packet for transmis- 
35 sion over a broadcast medium, the data packet comprising a 
data payload and an uncompressed packet header having 
muhiple fields, the method comprising the following steps: 
forming a compressed packet header comprising at least 
one, but not all, of the fields from the uncompressed 
40 packet header; 

appending the data payload to the compressed packet 
header; and 

appending a compression key to the compressed packet 
header, the compression key having a first block con- 
45 taining information to inform a receiver that the 
appended packet header is a compressed packet header 
and a second block containing an index to a table at the 
receiver that identifies the memory location of the 
uncompressed packet header. 
50 10. A method as recited in claim 9, further comprising the 
step of transmitting as a reduced-length data packet com- 
prising the compressed packet header, the data payload, and 
the compression key. 

11. A reduced-length data packet embodied on a trans- 
55 mission medium and constructed according to the steps 

performed at the server in the method as recited in claim 10, 

12. A compressed data packet embodied on a computer- 
readable medium constructed according to the steps per- 
formed at the server in the method as recited in claim 9. 

60 13. A computer programmed to perform the steps of the 
method as recited in claim 9. 

14. A computer-readable medium having computer- 
executable instructions for performing the steps of the 
method as recited in claim 9. 

65 15. A method for compressing an uncompressed packet 
header of a UDP/IP data packet to be transmitted over a 
broadcast medium, the uncompressed packet header having 
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an IP portion containing multiple IP fields and a UDP portion wherein the packet encoder appends a first bit value to 

containing multiple UDP fields, the method comprising the the full-length data packets and a second bit value to 

following steps: the reduced-length data packets to differentiate the 

forming a compressed packet header comprising at least full-length and reduced-length data packets; 

one, but not all, of the IP fields in the uncompressed 5 a transmitter at the server to transmit the full-length and 

packet header; and reduced-length data packets over the broadcast 

appending a compression key to the compressed packet medium; 

header, the compression key comprising a first block a receiver at the client to receive the full-length and 

containing information to inform a receiver that the reduced-length data packets from the distribution 

appended packet header is a compressed packet header medium; and 

and a second block containing an index to a table at the a packet decoder at the client to extract the header index 

receiver that identifies where the uncompressed packet values from the fiill-length data packets and store the 

header is or will be stored. uncompressed headers of the full-length data packets in 

16. A method as recited in claim 15, wherein the IP fields memory locations referenced by corresponding header 

include a packet identification field and a fragment field, the index values* and 

forming Step comprises the step of forming a compre^d ' ^ ^^j^^j ^^^j^; decompressor at the client to reconstruct 

packet header consisting of the packet identification held ju^ jr*i- ^uj- 

and the fi"a ment field uncompressed headers from the compressed headers m 

'\7.AmeroTasrecitedinclaiml5,whereintheIPfields reduced-length data packets, the packet header 

include a packet identification field and a fragment field, decompressor utilizing the header index values fram 

further comprising the following steps: 20 reduced-length data packets to reference the 

forming a 32-bit compressed packet header consisting of memory locations containing the associated uncom- 

the packet identification field and the fragment field; Pressed headers and reconstruct missmg fields in the 

appending a T-bit index value to the compressed packet compressed heade^ from the fields m die associated 

header, the index value containing an index to a table uncompressed headers. 

at a receiver that identifies where the uncompressed 25 25. A broadcast transmission system as recited in claun 

packet header is or will be stored; and 24, wherein the packet decoder stores the uncompressed 

appending a one-bit compression flag to the index value headers in a table at an entry identified by the corresponding 

that is used to inform the receiver that the appended header index values. 

packet header is a compressed packet header. 26. A broadcast transmission system as recited in claim 

18. A method as recited in claim 15, further comprising 30 24, wherein the packet decoder stores the uncompressed 
the step of appending a data payload to the compressed headers in a table according to a first-in-first-out protocol, 
packet header. 27. A broadcast transmission system as recited in claim 

19. A method as recited in claim 18, further comprising 24, wherein the packet decoder stores the uncompressed 
the step of transmitting as a reduced- length data packet headers in a table, the stored uncompressed headers being 
comprising the compressed packet header, the data payload, 35 considered expired after a predetermined time period 
and the compression key. elapses. 

20. A reduced-length data packet embodied on a trans- 28. A broadcast transmission system as recited in claim 
mission medium and constructed according to the steps 24, wherein the packet header decompressor temporarily 
performed at the server in the method as recited in claim 19. caches a compressed header in an event that the uncom- 

21. A compressed data packet embodied on a computer- 40 pressed header associated with the cached compressed 
readable medium constructed according to the steps per- header has not yet been received at the client. 

formed at the server in the method as recited in claim 15. 29. A broadcast transmission system as recited in claim 

22. A computer programmed to perform the steps of the 24, wherein the transmitter transmits a higher percentage of 
method as recited in claim 15. the reduced-length data packets in comparison to the full- 

23. A computer- readable medium having computer- 45 length data packets. 

executable instructions for performing the steps of the 30. A broadcast transmission system as recited in claim 

method as recited in claim 15. 24, wherein groups of the full-length and reduced-length 

24. A broadcast transmission system for transmitting data packets are formatted according to different transmis- 
full-length and reduced-length data packets from a server to sion protocols. 

a client over a broadcast medium, comprising: 50 31. A broadcast transmission system as recited in claim 

a packet header compressor resident at the server to 24, wherein the data packets are formatted according to an 

compress an uncompressed header with multiple fields UDP/IP protocol, the uncompressed headers have an IP 

into an associated compressed header with at least one, portion containing multiple IP fields and a UDP portion 

but not all, of the fields from an associated uncom- containing multiple UDP fields and the compressed headers 

pressed header; 55 have at least one, but not all, of the IP fields in the associated 

a packet encoder resident at the server to form full-length uncompressed header. 

and reduced-length data packets, the full-length data 32. A broadcast transmission system as recited in claim 

packets including a data payload and an uncompressed 31, wherein the IP fields include a packet identification field 

header and the reduced-length data packets including a and a fragment field and the compressed headers comprises 

data payload and a compressed header, the packet 60 the packet identification field and the fragment field, 

encoder further including with each full-length data 33. A data packet compressor for compressing a data 

packet a header index value, the packet encoder further packet for transmission over a broadcast medium, the data 

including with each reduced-length data packet the packet comprising a data payload and an uncompressed 

header index value of the full-length data packet that packet header having multiple fields, comprising: 

contains the uncompressed header that is associated 65 a packet header compressor to form a compressed packet 

with the compressed header within the reduced-length header having at least one, but not all, of the fields from 

data packet; the uncompressed packet header; 
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a packet encoder to append a header index value to the 
conopressed packet header, the header index value 
identifying for a recipient the uncompressed packet 
header from which the compressed packet header is 
formed; and 5 
wherein the packet encoder appends a bit value to the 
header index value to indicate that the appended 
header is compressed; 

the packet encoder further appending a data payload to the 
compressed packet header. 

34. A data packet compressor as recited in claim 33, 
wherein the data packet is formatted according to an UDP/IP 
protocol, the uncompressed header has an IP portion con- 
taining multiple IP fields and a UDP portion containing 
multiple UDP fields and the compressed headers has at least 
one, but not all, of the IP fields in the associated uncom- 
pressed header. 

35. A data packet compressor as recited in claim 34, 
wherein the IP fields include a packet identification field and 

a fragment field and the compressed header comprises the 20 
packet identification field and the fragment field. 

36. A data packet compressor as recited in claim 34, 
wherein the IP fields include a packet identification field and 
a fragment field, further comprising: 

the packet header compressor forms a 32-bit compressed 
packet header consisting of the packet identification 
field and the fragment field; and 

the packet encoder appends a 7-bit index value to the 
compressed packet header and a one-bit compression 
flag to inform the recipient that the appended packet 
header is compressed. 

37. A software program embodied on a computer-readable 
medium having code which implements the data packet 
compressor as recited in claim 33. ^5 

38. A data packet decompressor for decompressing a 
compressed data packet received from a broadcast medium, 
the compressed data packet comprising a data payload, a 
compressed packet header with one or more fields, a header 
index value, and a bit value to the header index value to ^ 
indicate that the appended header is compressed, compris- 
ing: 

a packet decoder to extract the compressed header from 

the compressed data packet; 
a packet header decompressor to access a memory loca- 45 

tion referenced by the header index value, the memory 
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location holding a full uncompressed packet header 
having multiple fields that include the fields in the 
compressed data packet and other fields missing from 
the compressed data packet; and 
the packet header decompressor rebuilding a decom- 
pressed packet header from the compressed packet 
header by adding the missing fields from the memory 
location to the fields in the compressed data packet. 

39. An operating system embodied on a computer- 
readable medium having code which implements the data 
packet decompressor as recited in claim 38. 

40. A network packet structure embodied on a computer- 
readable medium, comprising: 

a full-length data packet type comprising: 
a data payload; 

an imcompressed header appended to the data payload, 

the uncompressed header having multiple fields; 
a header index value to reference a memory location at 

a destination to hold the uncompressed header; 
a first bit value to identify the packet as the full-length 
data packet type; and, 
a reduced-length data packet type derived from the full- 
length data packet type comprising: 
a data payload; 

a compressed header appended to the data payload, the 
compressed header having at least one, but not all, of 
the fields found in the uncompressed header; 

the header index value; and 

a second bit value to identify the packet as the reduced- 
length data packet type. 

41. A network packet structure as recited in claim 40, 
wherein: 

the uncompressed header is a UDP/IP header having an IP 
portion containing multiple IP fields and a UDP portion 
containing multiple UDP fields; and 

the compressed header has at least one, but not all, of the 
IP fields in the associated uncompressed header. 

42. A network packet structure as recited in claim 40, 
wherein: 

the uncompressed header is a UDP/IP header that includes 
a packet identification field and a fragment field; and 

the compressed header consists of the packet identifica- 
tion field and the fragment field. 
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The invention relates to compressing and transmitting data 
on a connection between two parties in a telecommunication 
system comprising at least one slow transmission channel, 
such as the air interface Um of the radio network. The data 
to be transmitted are assembled into frames (F) comprising 
a header section (1) and a data section (2). Prior to 
transmission, at least the header (1) or the data section (2) of 
at least some of the frames (F) are compressed. The trans- : 
mitting party has available at least two different compression 
algorithms and the receiving party has available at least two 
different decompression algorithms. The transmitting party 
compresses at least one section (1, 2) of at least some of the 
frames (F) with at least two different algorithms, and trans- 
mits the frame (F) compressed with the algorithm that 
produced the best compression ratio. 
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DATA COMPRESSION ON A DATA algorithm, whereby the identifier indicating the algorithm 

CONNECTION used just adds to the length of the bit string. A further 

problem with the prior art compression carried out with a 
This application is the national phase of international fixed algorithm is that is does not oflfer optimal protection 
application PCT/Fl 97/00345 filed Jun. 3, 1997 which des- 5 against eavesdropping because the algorithm does not 

ignated the U.S. change. 

For example, PCT application WO 94/14273 discloses a 

BACKGROUND OF THE INVENTION system for compressing data to be transmitted with a number 

TTie invention relates to improving the capacity of data °f ^F^'^"^ compression means. However, the WO 94/14273 

transfer in a communication system, or more speciflcaUy a " aPPl^cation mamly relates to transmission of video informa- 

mobile communication system. ^"^'f^ Kc^i^cis simultaneously. Because the same 

, . ... , , . . . mformation is transmitted to several receivers, such a sys- 

FIG. 1 shows, from the pomt of view of the myention, the ^^^3^ ^ bottleneck comparable to the air 

essential parts of a «llular mobile communication system. j^^^^j^^ „f ^ ^y^^^ ^et radio network wherein unique 

MobUe stations (MS) communicate with base transceiver information is transmitted between each pair of transmitter 

stauons (BTS) over an air mterface Urn. m base stations ^^^^.^^^ ^^^^ 9MUm application assumes 

are controlled by base station controllers (BSC) which are ^^^^ compression method can be detemiined by the 

connected to mobile switching centers (MSG). A subsystem ^^^^^ „j transmitted information. Tliis assumption 

under control ofa base station controller BSC, includmg the ^^^^ ^^^^ ^^^^^^ transmission that the 

base stauons BTSn it controls, is commonly referred to as a information will be video information, 
base station subsystem (BSS). The interface between the 

mobile switching center MSG and the base station sub- BRIEF SUMMARY OF THE INVENTION 

system BSS is referred to as an A-interface. The part of the it is consequently the object of the invention to develop a 

mobile communication system at the MSG side of the method by means of which the limited capacity of the air 

A-interface is referred to as a network subsystem (NSS). 25 interface or another low-speed telecommunication resource 

Correspondingly, the interface between the BSC and the may be utilized as efficiently as possible, thereby simuita- 

BTS is referred to as an Abis interface. The mobile switching neously enhancing traffic encryption against unauthorized 

center MSG handles the connecting of incoming and out- listening. The objects of the invention are achieved by a 

going calls. It performs functions similar to those of an method which is characterized by that which is set forth in 

exchange of a public switched telephone network (PSTN). 33 the independent claims. The preferred embodiments of the 

In addition to these, it also performs functions characteristic invention are set forth in the dependent claims, 

of mobUe communications only, such as subscriber location invention is based on the notion that in a general case, 

management, jointly with the subscriber registers VLR and ^hen the contents of the data to be transmitted may be 

HLR of the network. As an alternative to the circuit switched arbitrary, the most efficient compression algorithm can be 

connection descnbed above, the connection to the mobile 35 established only experimentally. Because of this, the data to 

station MS may also take place via a packet network GPRS transmitted are, according to the invention, compressed 

(General Packet Radio Service). ^th a number of different algorithms, and the best of the 

One of the growing fields of application for mobile compression results is transmitted to the receiving party. The 

stations is to establish data links in connection with portable invention is further based on the view that it is worth while 

computers. Such a computer is represented by the computer 40 in a telecommunication system which contains a slow tele- 

PC in FIG. 1. The computer PC and the mobile station MS communication resource, such as an air interface limiting the 

may be separate units or they may form an integrated whole. capacity, to carry out a lot of extra computation in a location 

The data to be transmitted on data links is assembled into where that is cheap and where capacity enlargements may 

frames (F) that typically contain a header section 1 and a result from such an action. 

data section 2. If an increase occurs in the number and/or use 45 xhe method according to the invention utilises the band- 
of mobile stations, a bottleneck will be met in the form of the width of the bottleneck (such as the air interface in a 
transfer capacity of the air interface Um. The transfer telecommunication system) in the most effective manner 
capacity of the air interface may be increased by compress- possible because the compression algorithm is selected on 
ing the data to be transmitted over the air interface. The the basis of actual testing between different algorithms. The 
compression is based on some bit patterns in the data stream 50 method is applicable to several types of telecommunication 
being frequent and some occurring only once. The bit systems. The method according to the invention may be used 
patterns which occur frequently may be sent only once as a adaptively so that the transmitting party learns to apply a 
whole, and later it is possible to send only a reference to the specific algorithm on a specific connection. A further advan- 
bit pattern sent earlier. A number of such compression tage of the inventive method is provided by improvements 
algorithms has been developed,-including RLE (Run Length 55 regarding the protection of telecommunication as an eaves- 
Encoding) and LZ (Lempel-Ziv) with its different variants, dropper will have difficulties in interpreting a message 
JPEG, MPEG etc. Within the scope of this application, whose compression algorithm may change in the middle of 
compression ratio of an algorithm refers to the ratio between the connection, even between successive packets, 
the length of an imcompressed bit string (e.g. a frame) and 

the length of the bit string compressed with the algorithm in go SUMMARY OF THE FIGURES 

question. In the following, the invention will be described in closer 

The conventional packet communication described above detail in connection with its preferred embodiments and with 

encounters the problem that data of a specific type may be reference to the accompanying drawings in which: 

compressed more efficiently with a particular compression FIG, 1 shows the parts of the mobile communication 

algorithm whereas data of some other type may be com- 65 network that are significant to the invention, 

pressed more efficiently with another algorithm. Also such FIGS. 2A and 2B illustrate the steps of the inventive 

bit patterns exist that cannot be compressed with any compression. 
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DETAILED DESCRIPTION OF THE 
INVENTION 

With reference to FIG. 1, the invention will be described 
in an environment in which there is a mobile station MS and 
a computer PC connected thereto at the first end of the 
transmission channel, and at the other end a network sub- 
system NSS of which is shown a base station BTS, a base 
station controller BSC and a mobile switching center MSC. 
To keep the description simple, it is assumed that the 
compression and decompression algorithm according to the 
invention is implemented in the MS, but it may equally well 
be implemented in the PC. The preferred embodiment of the 
invention relates to enhancing the traflSc that takes place 
over the air interface Um, but in place of the air interface 
there may also be some other transmission channel having a 
limited capacity. 

In its simplest form, the invention may be applied so that 
a fixed set of compression and decompression algorithms are 
implemented in the mobile station MS and the network 
subsystem NSS. This set of algorithms is the same in the MS 
and the NSS, The transmitting party compresses each frame 
F with each algorithm it knows, and selects the algorithm 
that yields the best compression ratio. In addition, the 
transmitting party inserts an information field in the frame to 
be transmitted, indicating which algorithm the data have 
been compressed with. On the basis of this information field, 
the receiving party will know which algorithm to use in 
order to decompress the data. 

This simple implementation has at least two problems. 
Firstly, when using different equipments, the transmitting 
and receiving parties do not know in advance which algo- 
rithms have been installed at the counterpart. In addition, it 
is not possible to add new algorithms in the system without 
simultaneous updating of all the equipments in the system. 
Secondly, compressing each frame with all possible algo- 
rithms considerably increases requirements for computation 
capacity. The first of the problems may be solved by a 
negotiation protocol between the transmitting and receiving 
parties. The latter problem may be solved by optimizing the 
compression prooediure, e.g. by making it adaptive. 

In a mobile communication system, it could in principle 
be speculated that the negotiation for finding out the capa- 
bilities of the parties is unnecessary and that the features of 
each mobile station could be stored in a home location 
register or a similar equipment register. This arrangement 
would involve a lot of problems, the biggest of which 
probably having to do with the GSM type of systems 
maintaining the subscriber location by means of SIMs 
(Subscriber Identity Modules). If a SIM is shifted to another, 
for example a rented, terminal equipment, the system will 
assume that the second terminal equipment has the same 
capabilities as the original one. This assumption is not 
necessarily correct. 

For this reason, it is better to identify the capabilities of 
the transmitting and receiving parties at the beginning of the 
communication. In mobile communication systems, the 
negotiation must be carried out anew when the mobile 
station roams to a new area. A suitable and simple negotia- 
tion protocol is, for example, such that when taking new 
algorithms in use they are issued a running number, and at 
the beginning of the connection or in association with a 
location area change the calling equipment transmits an 
inquiry to the called equipment, concerning the available 
algorithms, to which the called equipment responds by 
sending a bitmap in which a bit set at an algorithm means 
that the algorithm is available. According to an alternative 
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negotiation protocol, the calling equipment transmits a short 
test message compressed with all the algorithms being 
tested, and the called equipment responds with an affirma- 
tive acknowledgment if it is capable of decompressing the 
5 message, and if it is not, with a negative acknowledgment. 
If there is installed, for each compression algorithm, both a 
compressing and a decompressing algorithm in the trans- 
mitting party as well as the receiving party, the common 
capabilities of the transmitting party and the receiving party 
10 may be identified so that e.g. the calling equipment identifies 
the capabihties of the called equipment. It is unnecessary for 
the called equipment to identify the capabilities of the 
calling equipment as the latter cannot have capabilities other 
than those it has already inquired of the called equipment. 
15 On the other hand, it is mathematically considerably 
simpler to decompress a packet than to compress it. This 
holds particularly well true regarding compression of live 
video images and fractal algorithms, especially. 
Consequently, it could also be conceivable to implement e.g. 
20 in mobile stations a larger number of algorithms for decom- 
pressing a packet than for compressing it. In such a case, the 
negotiation protocol may be supplemented so that also the 
called equipment identifies the capabilities of the calling 
equipment. 

For an efficient compression of data, the compression 
must take place prior to encryption and sphtting the data into 
frames. According to an embodiment of the invention, the 
header sections 1 of the frames F are compressed with a 
specific type of algorithm and the data sections 2 of the 
frames F are compressed with at least two different algo- 
rithms of which the one is selected that provides the best 
compression ratio. The header section is compressed with an 
algorithm optimized for this purpose, said algorithm being 
substantially the same from one frame to another. 

For example, when transmitting user-entered characters in 
TCP/IP frames in a Telnet connection, each character 
entered is normally sent in its own frame. This is because the 
user awaits a relatively quick response, after no more than 
approximately 0.2 seconds from entering the character. On 
the other hand, the transmitting program does not know at 
which moment the next entering is to take place, which 
means that each character has to be sent as a separate firame 
consisting of 40 bytes of header and 1 byte of data. The 
reference [1] discloses a method for compressing the header 
sections of TCP/IP frames into 3-5 bytes. The method 
according to the reference [1] utilizes the fact that in the 
header sections of TCP/IP fi"ames a lot of information is sent 
that the receiving party is able to form by itself on the basis 
of the header section in the previous frame. Similar redun- 
dancy is present e.g. in header sections of ATM cells. 

The compression algorithm employed may be indicated to 
the receiving party for example by transmitting, in each 
compressed frame F, an identifier indicative of the compres- 
55 sion algorithm used. Alternatively, the receiving party may 
be sent information on the change in the compression 
algorithm. This information may be a separate frame, or a 
field or a peculiar bit pattern inserted to a fi"ame normally 
transmitted. 

60 To utilize the air interface as efficiently as possible, it is 
advantageous to carry out the compression procedure during 
those moments when the transmitting party for a reason or 
another may not transmit. In the GSM system, for example, 
the data are transmitted over the air interface as bursts in 

55 TDMA timeslots. Between the bursts, the transmitting party 
can perform the necessary computations and thus utilize its 
computation capacity that it would otherwise waste just 
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waiting for the next timeslot. At the allocated timeslot, it is maintained for each algorithm, illustrating its eflSdency, 

possible to interrupt the compression and to transmit the such a parameter being for example the sliding average of 

frame compressed with the algorithm that up to that point the compression ratio. At step 220, the data section 2 is 

has produced the best result compressed with as many of the remaining algorithms as 

Tlie foUowing discusses various options for reducing the s possible within the time supervision in this example with 

^ . ♦ -ru ^oo,' two algonthms. The identifiers of the algonthms tested at 

computation requirements. The compression procedure can ,u „ * j- j « *■ * * I'^n 

• • J L r 1 • iL. 11 this step are stored in memory, and next time at step 220, 

be optmiized by for example compressmg a frame F with all ^^^^^ algorithms are tested. The testing may be beguS with 

the algonthms used, i e those that were m the negotiations algorithm that follows the one tested last. When the time 

found to be supported by both parties. supervision 225 expires, for example when a transmission 

The frame F that is compressed with all the algorithms turn approaches, the order from best to worst of the algo- 
employed is preferably the first one representing a specific rithms is updated at step 230, and the data are transmitted at 
type of data, i.e. when the data type changes, the testing with step 235 compressed with the algorithm that produced the 
the algorithms may be started from the beginning. The best result within the time available, 
subsequent frames are each first compressed with the algo- The preferred embodiment of the invention relates to 
rithm that at the previous frame yielded the best result. The compressing data on a communication link and particularly 
other compression algorithms are not necessarily completed. in a packet radio network. The invention is applicable for use 
Their processing may be interrupted immediately as the in other types of telecommunication systems and in data 
length of the compressed frame obtains the length of the processing systems which have at least one distinct bottle- 
algorithm compressed with the optimal algorithm. neck restricting the capacity of the entire system. Therefore, 

According to another embodiment, a sliding average of is obvious for a person skiUed in the art that upon 

the compression ratio is maintained-for each algorithm with advancements m technology the basic idea of the mvention 

which a frame has been compressed. The frames are com- ^^^y be implemented in many ways. The invention and its 

pressed with different algorithms in an order determined by embodiments are consequently not restricted to the 

the compressing ratio obtained with the algorithms. If the examples described above but they may vary within the 

compression ratio of a frame with some algorithm exceeds scope of the claims, 

a predetermined threshold value, the frame in question will References 

not be compressed with the other algorithms. The predeter- r.-,,,x . ^ . r.,™„„. , ^ , 

mined threshold value may be a fixed multiplier, for example t^] V. Jaoobson: Compressmg TCP/IP headers for low-speed 

a number between 3-^. Alternatively, the threshold value ^^^^^ (^^^f .^^^ ^or Comments 1144). 

may be a specific percentage, for example 80-90% of the ^^^^^ ^ clauned is: 

compression ratio achieved with the best algorithm up to 1' ^ "^^^^^^ compressmg and transmitting data on a 

that point connection between two parties in a telecommumcation 

jn,, -1 ui • 4 «r * *f • u system comprising at least one slow transmission channel 

If the time available is not sufficient for compressing each . *u j 

r .1 -.1. • J- -J 1 r L (Um), the method comprising: 

frame with each algorithm, the individual frames may be ,c ^ . . , . ^ 

compressed for example with those 1-3 algorithms that up assembhng the data to be transmitted mto frames (F) 

to that point show the best sliding average for the compres- '^^'r^ ^T"^ " ' ' ' 

sion ratio. The remaining time — e.g. when waiting for the section ( ), an 

transmission turn— is spent on testing the remaining algo- compressmg at least one section (1, 2) of at least some of 

rithms one at a time. This is illustrated by the following ^ W P"^^ transmission, 

example. It is assumed that there are 7 different algorithms making at least two different compression algorithms 

available, and when waiting for each transmission timeslot available to the transmitting party, 

there is time to test four of them. In such a case, at each making at least two different decompression algorithms 

timeslot, compression may be carried out with those two available to the receiving party, 
algorithms that up to that point have yielded the best result. 45 characterized in that the transmitting party: 

Of the other five algorithms, two are tested at each timeslot. compresses at least one section (1, 2) of at least some of 

Encryption may further be improved if the algorithms are the frames (F) with at least two different compression 

during the negotiation numbered in an order determined on algorithms; 

the basis of a pseudorandom number known only to the selects the compression algorithm that yielded the best 

parties. The same outcome may be reached by changing the 50 compression ratio; and 

identifiers of the algorithms, at a specific algorithm during transmits the frame (F) over the slow transmission chan- 

the connection. It is advantageous to carry out the negotia- nel (Um) to the receiving party, compressed with said 

tion in an encrypted form. With these methods the advantage selected compression algorithm, 

is obtained that the compression algorithm identifiers trans- 2. A method as claimed in claim 1, characterized in that 
mitted along with the frames are not unequivocal to eaves- 55 the parties negotiate the compression algorithms to be used 

droppers. on the connection at least at the beginning of the connection. 

FIGS. 2A and 2B illustrate some of the steps in the 3. A method as claimed in claim 2, characterized by the 

compression method of the invention. At step 200, the first party sending to the second party an inquiry concerning 

compression routine receives the data to be transmitted and the available algorithms, to which the second party responds 
compressed from the application producing them. Step 205 60 by sending a list containing information on the algorithms 

illustrates the operations in which time supervision is set to available to the second party. 

ensure that the data are transmitted on time, for example in 4. A method as claimed in claim 2, characterized by the 

the next transmission timeslot. At step 210, the header 1 of second party selecting the algorithms that both the parties 

the frame F is compressed with an algorithm optimized for support from the list sent by the first party, 
this purpose. At step 215, the data section 2 is compressed 65 5. A method as claimed in claim 2, characterized by the 

by a few, in this case three, of the best algorithms up to that second party transmitting a list of the algorithms available to 

point. In association with the compression, a parameter is it regardless ofwhich algorithms the first party has available. 
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6. A method as claimed in claim 2, characterized by the 
first party transmitting a brief test message compressed 
separately with each algorithm being tested, and the second 
party responding with an afl&rmative acknowledgment if it is 
capable of decompressing the message, and if not, with a 5 
negative acknowledgment. 

7. A method as claimed in claim 2, characterized in that 
both parties have a decompression algorithm available for 
substantially each compression algorithm. 

8. A method as claimed in claim 2, characterized in that ao 
at least one of the parties may have available a decompres- 
sion algorithm without a corresponding compression algo- 
rithm or vice versa, and that the parlies negotiate separately 
the compression and decompression algorithms available to 
them. 35 

9. A method as claimed in claim 2, characterized in that 
the negotiation between the parties is transmitted on an 
encrypted channel. 

10. A method as claimed in claim 2, characterized in that 
the identifiers of the compression algorithms are changed 20 
between successive connections and/or during one connec- 
tion. 

11. A method as claimed in claim 1, characterized by 
compressing the header sections (1) of the frames (F) with 

an algorithm which is substantially the same between 25 
two successive frames (F), and 
compressing the data sections (2) of the frames (F) with 
at least two different algorithms of which the one is 
selected that yields the best compression result. 

12. A method as claimed in claim 1, characterized by 
transmitting, with each compressed firame (F), an identifier 
indicative of the compression algorithm used. 

13. A method as claimed in claim 1, characterized in that 
when the compression algorithm changes the transmitting 
party separately transmits information on the change to the 
receiving party. 



14. A method as claimed in claim 1, characterized by 
compressing a frame (F), which is advantageously the 

first one representing a specific type of data, with 
substantially all the algorithms known to both parties, 
compressing the subsequent frames (F) first with the 
algorithm that at the previous frame (F) produced the 
best result, 

discontinuing to carry out the other algorithms if the 
length of the frame (F) compressed with the algorithm 
in question exceeds the length of the frame (F) com- 
pressed with up to that point the best algorithm. 

15. A method as claimed in claim 1, characterized by the 
transmitting party being assigned a restricted time for the 
compression, such as the time between two successive 
transmit turns in time division multiple access systems. 

16. A method as claimed in claim 15, characterized in that 
at the end of the restricted time the transmitting party 
discontinues testing the compression algorithms and trans- 
mits the frame (F) compressed with the algorithm that up to 
that point has yielded the best compression result. 

17. A method as claimed in claim 16, characterized by 
maintaining, for the different compression algorithms, a 

parameter indicating efficiency, advantageously a slid- 
ing average of the compression ratio, 

compressing each firame (F) or a section (1, 2) thereof 
with a few, advantageously 1-3 of the best compression 
algorithms up to that point, in an order determined by 
the parameter indicating efiSciency, and 

testing, in the remaining part of the restricted time, the 
remaining algorithms alternately so that at successive 
firames (F) different algorithms are tested. 
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network bandwidth cause by numerous acknowledgment 
transmitted by the receiver to the transmitter by providing 
sparse feedback from the receiver to the transmitter indicat- 
ing receipt of packets having headers to be used as reference 
headers. In the invention, upon receipt in the receiver of a 
packet having a reference header, a feedback is provided to 
the transmitter indicating receipt of the packet having the 
reference header. Thereafter, the receiver waits a predeter- 
mined period of time before providing another feedback in 
response to another packet having a reference header. The 
predetermined period of time allows time for the feedback to 
be received by the transmitter and for information from the 
transmitter indicating receipt of the feedback to be received 
by the receiver. 
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USING SPARSE FEEDBACK TO INCREASE The first type of compressed header is used when the 

BANDWIDTH EFFICIENCY IN HIGH DELAY, subsequent headers of the subsequently transmitted packets 

LOW BANDWIDTH ENVIRONMENT can be extrapolated in a linear fashion from the previous 

header. In this setting, the compressor transmits sequence 
5 numbers as the compressed headers. This type of com- 

BACKGROUND OF THE INVENTION pressed header is referred to as Second Order (SO) header 

TTie present invention relates to a method and apparatus IJ,™"? hl^/.^ ofT^T"* ^ "^'^ IT*''", 

for eliminating the inefficient use of network ba^width c^foTbe L.rlLn ^"^"ri.^^ "TT '"^ ^''^T 

caused by numerous acknowledgements transmitted by a "Zn ' 'L'^'Y ^'f ° '^.'^ f """8' 

receiver to a transmitter by providing sparse feedback from '° ru'enTnumbT^f ,h' "^^TT "^^^^^ '^t 

the receiver to the transmitter to indicate receipt of packets f • f'^P'/^ headers. This type of 

having headers to be used as reference heade.^. heX Se va lJ^^fTf 'I'.-^'^l °f ' 

c , . , n . , , , . . Deader. J he bO header contams additional information 

For Internet Protocol (IP) based real-Ume multimedia which is required to accurately decompress the compressed 

applications packets are used to carry the real-time daU. headers of the subsequently transmitted packets. In RFC 

Each packet includes a header and a payload. The header 2508. all headers that are decompressed are stored as ref- 

carnes information such as source and destination addresses erence headers. In order to decompress the current header, 

of the packet and the payload carries the data to be trans- the decompressor must have correctly decompressed the 

ELe wtr ^ir?R^^^^^^ '°^ Previousheader.Inpractice.itisnotuncommonforpackets 

,7^7 . f? (RTP) which IS predommately having compressed header to be lost or corrupted during 

rJnh H ^° ^'''.n^'^'^ ^'^ transmission. TTiis results in the compressor and decomS 

described m detaJ m "RTP: A Transport Protocol for Real- sor staying in a less then optimal sfate for some 3?d 

Tmie Applications" by H. Schulzrmne, et al, Internet Engi- time. The same can occur due to Round Trio delavs in 

neenng Task Force (IETF) Request for Comments (RFC) receiving the packets having compressed header^ 
889, January 1996. Tlie size of a combined IP/UDP/RTP „ Consequently, the data st.ar^s^e^rproild by 

llV:fo7^'r^:^^tT^^^^^ -p:essoranddecompre^rmayreqL^dditionalbU 

^:^r^^s^ RFc°SoTr dt"^^''^' '^"T^^"" -'r ''^-^"^ ^ 

concern. Consequently, a need arises for suitable IP^DP/ ^ ,h ' ''""'^.P^'^^' 'f'^™'^ acknowledgements 

RTP header compre J^n mechan^. ^ ^ nacLtTfcT' °^ ' " 

A . L J 1^ Packet. 1 he compressor m response to an acknowledgement 

A current header impression scheme is described in indicating receipt of a FH packet switches to an FO stote and 

•Compres^ng IP/UDP/RTP Headers for Ix.w-Speed Serial begins transmitJing FO header packets Xe linear extrano 

« 'neaderr f^J^^f ' ^^"""^ '''' ^^'^^^^ or 'switches to the S^^^^^^^^^^ 

Sf Lc S7?eZ?™mg !'^?i°^'^™«i°gSOheaderpacketswherelinearextrapo- 

v! A ^ J ^^^Z^^- ^ header compression lation can be conducted. Similar to an FH packet the 

VO^!o^o^tnZ ^i^'JT ' '^f ::«'=«P'°f^°F01>eaderpacket,swi,chestotheSOstateand 

pomt-to-point links. This header compression scheme is begins transmitting SO header packets 

5.r™^V I °f headers of « In error/loss prone communication enviromnents such as 

the packets remam constant in a packet stream during the cellular, the decompressor cannot T ceTai^ ,hTt Z 

length of a session. Thus, it is possible to compress the acknow edgment has been prSerly received bv the com 

f~Sr'''°° T''^'^"^ ^' compression state pressor until it sees an alL'XL^f^ lie p m of the' 

(context) at a compressor (transmitter) and a decompressor compressor. Namely, the decompressor in Lnventbnal 
ZZL f ^h''^°^ compressed headers are then 45 apparams is not awL that the acLoTledgmem Cbeen 

muted from the compressor to the decompressor, properly received, until it sees that the S^s^r ha^ 

deader s,tH'°'°'Tf '° ' '"^"""^ '^^''^ ''^ T^*' ^' decompreZT FO 

header stored as par of the compression state. Each com- header packets instead of FH packets or SO header packete 

Sn?:, '""""^ " T.'"""""" ^^Tu' i°«tead of FO header packets. In the mean iirne the decom 
?el^jT.h H the conapres^d header is decom- 50 pressor keeps sending acknowledgments to headers of each 

SeSn ''""""P"^"' "'^ ^^'^''^^hed com- of the packets received. Further, The decompressed in ^n- 

r DC- ^.cno .u . ventional apparatus remains unaware that the acknowledg- 

n RFC 2508 the changes occurring in the RTP header ment has been properly received due to round trip delays in 

helds Irom one packet to the next, such as the RTP time receiving packets resulting torn the altered behavior of the 

stamp can be predicted by linear extrapolation from the 55 compressor. Thus, the conventional technique suffers from 

precedmg header which was received without error. Thus, in the disadvantage of inefficient use of bandwidth of the 

an RIP header the primary information that is sent is a network. 

sequence number which is used for packet loss detection. To FIG. 1 graphicaUy iUustrates the inefficient use of the 

mitiate a session or to re-synchromze a compression state bandwidth of a network resulting from sending acknowl- 

between a compre^and decompressor, a packet contain- 60 edgments in response to each and every FH packet or FO 

ing a Full Header (FFQ is transmitted from the compressor header packet even after a first acknowledgment has been 

to he decompie^or. The FH contains all of the information sent. According to the above, as each FH packet or FO 

of the header of the packet and is used (stored) as a reference header packet is received an acknowledgment is transmitted 

header_ After a session has been initialized or from the decompressor to the compressor acknowledging 

re-synchronization has been performed. aU subsequent pack- 65 receipt of the FH packet or FO header packet In HG 1 1^ 

els are transmitted with compressed headers. The com- is assumed that at time .„ an FO(n) header packet 'is 

pressed headers are. for example, of two types. transmitted from the compressor and detected by the decom- 
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pressor at time tj. Further, at time t^ the decompressor, in mined period of time before providing another feedback in 

response to the FO(n) header packet transmits an acknowl- response to another packet having a reference header trans- 

edgment (ACK(n)) to the compressor. In FIG. 1 it is mitted by the transmitter. 

assumed that T^^ is the transmission delay from the decom- The predetermined period of time the receiver waits 
pressor to the compressor, IS the transmission delay from 5 before providing another feedback allows for receipt of 

the compressor to the decompressor, T,^^ is the time information from the transmitter indicating that the trans- 

interva between consecutive media samples inserted into niitter has received the feedback. The predetermined period 

the packet, ACK (n) is an acknowledgment transmitted from of time could, for example, correspond to the Round Trip 

the decompressor upon receiving aii FH packet or an FO(n) jime of a packet sent from the receiver to the transmitter and 
header packet, and SOC+T^^T^J/T,^^^) is an SO header lo back. 

packet sent by the compressor in response to receipt of the tt,^ . *u . . l 

ACK(n) ^ r ^ i- The information returned by the transmitter to the receiver 

A J- » oir. 1 f . c ^ ^ in response to the feedback could, for example, be informa- 

According to FIG. 1, from time forward, the compres- tion indicating that the transmitter has altered its behavior, 

sor continues sendmg FO header packets through time t. Specifically, the information could, for example, be a packet 
untU the ACK(n) has been received at the compressor at Ume 15 ^^^^^ ^ compressed header which corresponds io the 

t,. nie decompressor, in response to each FO header packet reference header. Such a packet can, for example, be a SO 

transmitted subsequent to the FO(n) header packet, transmits header. , ow 
an ACK to the compressor. At time t^, once the ACK(n) has 

been received, the compressor begins transmitting SO BRIEF DESCRIPTION OF THE DRAWINGS 
header packets to the decompressor. At a time subsequent to 20 

time t2 the decompressor receives the firet one of the SO The present invention will be more apparent from the 

header packets, thereby indicating that the ACK(n) was Allowing detailed description, when taken in conjunction 

properly received at the compressor. The decompressor then accompanying drawings, in which: 

stops transmitting ACK's to the compressor. FIG- 1 illustrates the inefiGcient use of the bandwidth of a 

Thus, as is clearly illustrated in FIG. 1 in the time between network system according to the conventional technique; 

time to and t^, FO header packets are still being sent from the F^G. 2 illustrates an example of a network system archi- 

corapressor, and the decompressor in response to each of tecture in accordance with the present invention; 

these FO header packets sends an ACK, thereby occupying FIG. 3 illustrates the efficient use of the bandwidth of a 

precious bandwidth in the network. Therefore, the conven- network system according to the technique of the present 

tional technique causes inefficient use of the bandwidth of a invention; and 



network. 



FIG. 4 illustrates the efficient use of the bandwidth of a 

SUMMARY OF THE INVENTION network system according to the technique of the present 

invention. 

The present invention provides a method and apparatus 

for eliminating the inefficient use of network bandwidth DESCRIPTION OF THE INVEN^HON 

caused by numerous acknowledgments transmitted by the The features of present invention are iUustrated for 

receiver to the transmitter by providing sparse feedback example, in FIGS. 2^. However, it should be understood 
from the receiver to the transmitter to indicate receipt of that the present invention is not limited thereto and can be 

packets havmg headers to be used as reference headers. implemented in other architectures. The present invention is 

The present invention is applicable to a network system described below as being applicable to a system whereby a 

where spectral efficiency is a concern. The present invention compressor and a decompressor is used so as to transmit 

can also be applied where the compression of the headers of packets having compressor headers. However, the present 

packets which are transmitted in a network system would invention can be applied to any system where bandwidth 

provide some efficiencies in the use of the bandwidth of the 45 requires conservation and a reduction in the number of 

network system. In such a network system, a compression acknowledgments transmitted from a receiver to a transmit- 

state is estabUshed on a link or communication channel ter would improve bandwidth efficiently, 

between a transmitter (compressor) and receiver The network system of the present invention as iUustrated 

(decompressor) so that packets transmitted between the in FIG. 2 provides a terminal 102 which is connected to an 

compressor and decompressor on the link or communication 50 IP network 108. The terminal 102 can, for example, be a 

channel are sent with compressed headers. The compression personal computer, telephony apparatus, host, laptop or any 

state is established by storing information corresponding to other such apparatus which executes processing in accor- 

information contained in the header of a packet as a context dance with IP/RTP/UDP. Particularly, the terminal 102 can 

in both the compressor and decompressor, when the header provide packets of voice samples which are formatted 

IS to be used as a reference header. The compressor and 55 according to RTP for transmission over the IP network 108. 

decompressor can, for example, each be separate apparatus In order to accomplish this, the terminal 102 includes an 

provided in the network system or provided as a part of, for RTP endpoint 104 which identifies terminal 102 (e.g., 

example, a router, a host, a teraainal or any other such including IP address, port number, etc) as either a source and 

apparatus included in the network system. destination of RTP packets. While the IP network is provided 

In the present invention, a packet having the header to be 60 as an example, other types of packet switched networks can 

used as a reference header is transmitted from the transmitter be used in place thereof. Terminal 102 also includes a local 

to the receiver. Such a packet can, for example, be a FH timer 103 for generating a time stamp, 

packet or a FO packet. According to the present invention, An Access Network Infrastructure (ANI) 110 is connected 

the receiver receives the packet having the reference header to the IP network 108. A wireless terminal 130 is coupled via 

and m response provides a feedback to the transmitter 65 a Radio Frequency (RF) link 140 to the ANI 110. The RF 

mdicating receipt of the packet having the reference header. link 140 includes a up-link 142 which transmits data from 

After providing the feedback, the receiver wails a predeter- the terminal 130 to the ANI 110 and a down-link 144 which 
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transmits data from the ANI 110 to the terminal 130. ANI 
110 interfaces one or more wireless or RF terminals includ- 
ing terminal 130 located in different areas of a region to IP 
network 108. ANI 110 performs functions such as convert- 
ing between wireline signals provided by the IP network 108 
and wireless or RF signals provided by terminals such as 
terminal 130. Thus, ANI 110 allows RTP packets received 
from the IP network 108 to be sent over RF link 140 to 
terminal 130 and allows RTP packets received from, for 
example, terminal 130 to be sent over the IP network 108 to, 
for example, terminal 102. 

According to the present invention, ANI 110 includes one 
or more ANI adapters (AN1_AD) such as ANI_AD 112 and 
ANI^AD 114. Each of the ANI-AD's includes a timer 113 
and performs header compression on RTP packets prior to 
transmitting the packets on the down-link 144 to terminal 
130 and performs header decompression on RTP packets, 
after being transmitted on the up-link 142 from terminal 130. 
The header of each packet includes one or more fields such 
as a time stamp field. The header of each packet recieved 
from the IP network 108 is compressed according to RFC 
2508 by ANI-AD 112 prior to transmission to terminal 130 
on down-link 144. The header of each packet received from 
the terminal 130 over the up-link 142 is decompressed 
according to RFC 2508 by ANI_AD 112 before transmis- 
sion to IP network 108. Therefore, each ANI_AD serve as 
a compressor and/or a decompressor (compressor/ 
decompressor 115). Thus, the compression/decompression 
function according to RFC 2508 can be implemented in any 
of the apparatuses included in the system (e.g., routers, 
hosts, telephony apparatuses, etc.). 

Each ANI_AD interfaces terminals located in a specific 
area within a region to the IP network 108 and makes use of 
the timer 113 ifor implementing a timer-based compression/ 
decompression techniques. ANI_AD 112 also includes a 
jitter reduction function (JRF) 116 which operates to mea- 
sure the jitter on packets (or headers) received over the IP 
network 108 and discard any packets/lieaders having exces- 
sive jitter. Additional ANI*s such as ANI 120 are, for 
example, provided for interfacing other terminals located in 
other areas of other regions to the IP network 108. ANI 120 
similarly includes one or more ANI_AD's such as ANI_ 
AD 122 which includes at least a timer and a JRF as 
described above. 

Terminal 130 includes an RTP endpoint 132 which iden- 
tifies terminal 130 (e.g., including IP address, port number, 
etc) as a source and/or destination of RTP packets. Terminal 
130 also includes a terminal adapter (TERM_AD) 136 
which performs header compression on the headers of 
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15 



In order to illustrate the features of the present invention 
as it relates to FIG. 2 the following assumptions are made. 
Data, including, for example, voice, in the form of packets 
are transmitted from terminal 102 through the IP network 
108 to the terminal 130 via ANI 110, ANI_AD 112 and the 
down-link 144. In order to conserve the bandwidth of the 
down-link 144, the headers of each of the packets transmit- 
ted from the terminal 102 are compressed by the 
compressor/decompressor 115 which form part of ANI_AD 
112. The packets having the compressed headers are trans- 
mitted by the compressor/decompressor 115 over the down- 
link 144 to the terminal 130. The terminal 130 including a 
compressor/decompressor 137 decompresses the headers of 
the packets transmitted over the down -link 144 to obtain the 
original packets. The original packets are then processed by 
the terminal 130. 

In order to initiate a session between the compressor/ 
decompressor 115 and the compressor/decompressor 137 or 
re-synchronize a compression a state between the 
compressor/decompressor 115 serving as a compressor and 
the compressor/decompressor 137 serving as a 
decompressor, a packet containing a reference header such 
as Full Header (FH) or a First Order (FO) header is trans- 
mitted from the compressor 115 to the decompressor 137. 
The FH or FO header contains information corresponding to 
the fields of a header of a packet. Such information is stored 
as a reference header (context) in the compressor 115 and the 
decompressor 137. After a session has been initialized or 
re-synchronization has been performed, all subsequent pack- 
30 ets to be transmitted from the compressor 115 to the decom- 
pressor 137 are transmitted with compressed headers. The 
compressed headers can, for example, be of two types. The 
first type of compressed header is used when the headers of 
the subsequently transmitted packets can be extrapolated in 
35 a linear fashion from the reference header. This type of 
compressed header is referred to a as a Second Order (SO) 
header. The FO header is the second type of compressed 
header. The FO header is used when the headers of the 
subsequently transmitted packets cannot be extrapolated in 
40 a linear fashion. As per the above, both the FH and the FO 
headers are used as reference headers. 

Upon receipt of either an FH packet or an FO packet the 
decompressor 137 provides a feedback to the compressor 
115 indicating receipt of the FH packet or the FO packet. It 
45 should be noted that the compressor 115 continues to send 
FH packets or FO header packets until a feedback from the 
decompressor 137 has been received indicating proper 
receipt of the FH packet or the FO header packet. The 
feedback from the decompressor 137 is sent to the compres- 
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packets to be transmitted over the up-link 142 and header so sor 115 over the up-link 142. 



decompression on the headers of packets received over the 
down-link 144. Thus, TERM__AD 136 serves as a compres- 
sor or a decompressor (compressor/decompressor 137) simi- 
lar to ANI_AD. TERM_AD 136 includes a timer 134 for 
calculating an approximation of a RTP time stamp of a 
current header and to measure elapsed time between suc- 
cessively received packets. 

The configuration illustrated in FIG. 2 is an example of a 
system in which the present invention is practiced wherein 
RTP packets are transmitted over a link or communication 
channel such as the wireless link 140 where bandwidth is at 
a premium and errors are not uncommon. However, the 
present invention is not limited to a wireless link but may in 
fact be applicable to a wide variety of links or communica- 
tion channels including wireline links. The present invention 
may, for example, find appfication in packets which are used 
for voice over IP network or IP telephony. 



In the conventional technique, an acknowledgment is sent 
by the decompressor 137 in response to each and every FH 
packet or the FO header packet which are continually sent by 
the compressor 115. Thus, the conventional technique inef- 

55 ficiently uses the bandwidth of the up-link 142. 

The present invention conserves the bandwidth in the 
up-link 142 by causing the decompressor 137 to send a 
feedback in response to a FH packet or a FO header packet 
and then wait a predetermined period of time before sending 

60 another feedback in response to FH packets or FO header 
packets which are continually being transmitted by the 
compressor 115, Thus, the decompressor 137 transmits one 
feedback over the up-link 142 in response to the FH packet 
or the FO header packet and waits for an indication from the 

65 compressor 115 that the feedback has been received. If after 
the predetermined period of time has expired, an indication 
that the compressor 115 received the feedback has not been 
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received then the decompressor 137 sends another feedback 
in response to a subsequently transmitted FH packet or FO 
header packet. 

The predetermined period of time during which the 
decompressor 137 waits before sending another feedback in 
response to a subsequently transmitted FH packet or FO 
header packet, allows time for the feedback to traverse the 
up-link 142 to the compressor 115 and time for the indica- 
tion of receipt of the feedback by the compressor 115 to 
traverse the down-link 144 back to the decompressor. The 
predetermined period of time could, for example, corre- 
spond to the Round-Rrip-Time (RTT) it would take for a 
packet transmitted from the decompressor 137 to the com- 
pressor 115 over the up-link 142 and for the packet to be 
returned back to the decompressor 137 over the down-link 
144. The information from the compressor 115 indicating 
that the compressor has received the feedback could be 
information indicating that the compressor 115 has altered 
its behavior by, for example, sending SO header packets. 

The basic feature of the invention is that it is more likely 
than not that the feedback transmitted by the decompressor 
137 to the compressor 115 will properly traverse the link 
between the decompressor 137 and compressor 115 so as to 
cause the compressor 115 to alter its behavior. Since it is 
more likely than not for the feedback to properly traverse the 
Hnk between the decompresssor 137 and the compressor 
115, then it would be on rare occasions that the feedback is 
not received by the compressor 115, When such occurs, the 
decompressor re-transmits another feedback in response to a 
subsequently transmitted FH packet or the FO header 
packet. 

The technique of the present invention is particularly 
illustrated in FIG. 3. In FIG. 3, similar to FIG. 1, where T^^ 
is the transmission delay from the decompresssor 137 to the 
compressor 115, T^^ is the transmission delay from the 
compressor to the decompresssor 137, T^amp is the time 
interval between consecutive media samples, HDR(n) is a 
packet having a header that can be used as a reference header 
(FH or FO header) transmitted from the compressor 115 
with a sequence number n, FB(n) is a feedback sent from the 
decompresssor 137 to the compressor 115 upon receiving a 
packet with the header HDR(n), T^^ is the round-trip 
delay for a packet to traverse the link between the decom- 
pressor 137 and compressor 115 and back, where T,^^ 
equals T^^T^^, CH and is a packet having a compressed 
header that may be of the FO less optimal state or the SO 
more optimal state. 

As illustrated in FIG. 3, at time to the compressor 115 
transmits a packet having a header HDR(n) to the decom- 
presssor 137. At time tj the decompressor 137 detects the 
packet having the header HDR(n) and in response transmits 
the feedback FB(n) to the compressor 115. In the meantime, 
the compressor 115 continues to transmit packets having the 
header HDR through time t^ . The decompresssor 137 after 
transmitting the feedback FB(n) to the compressor 115 waits 
a predetermined period of time corresponding to, for 
example, T^^^^. In other words, the decompresssor 137 does 
not send another feedback to any further packets having the 
header HDR until the time T^^ has elapsed. 

Once the compressor 115 receives the feedback FB(n) at 
time t2, the compressor 115 alters its behavior and begins 
sending packets having compressed headers CH(n+T^^+ 
^dJ^samp) The decompresssor 137 receives the CH(n+T^^+ 
TrfJ/T^am/j) packets having the compressed headers from the 
compressor 115, thereby indicating that the feedback FB(n) 
was properly received by the compressor 115. 
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FIG. 4 illustrates a situation according to the present 
invention where the feedback FB(n) was lost due to, for 
example, a link layer error. In such a situation, the decom- 
presssor 137 waits until the predetermined period of time 

5 has elapsed and then determines that no information or 
indication has been transmitted from the compressor 115 
that the feedback FB(n) has been received. The decompress- 
sor 137 then transmits another feedback FB to the compres- 
sor 115 in response to a subsequently transmitted packet 

10 having a header HDR and waits for another predetermined 
period of time. Of course, if the compressor 115 does not 
transmit an indication that the re-transmitted feedback FB 
has been received, then at the very least the compressor 115 
and decompressor 137 would remain in a less optimal state. 

15 The less optimal state is where packets having headers 
which are to be used as reference headers (FH or FO) are 
transmitted. 

Even where an indication of receipt of the feedback has 
not been received, the present invention offers advantages 

20 being that there still is a reduced nmnber of feedback 
transmitted from the decompressor 137 to the compressor 
115 relative to the number of acknowledgements that would 
be transmitted according to the conventional technique. 
According to the present invention, subsequent feedbacks 

25 are only sent after the predetermined period of time has 
elapsed. Thus, the present invention provides for a sparse 
number of feedbacks to be transmitted from the decompres- 
sor 137 to the compressor 115. 

According to the above, the present invention provides a 
method and apparatus for eliminating the inefficient use of 
network bandwidth caused by numerous acknowledgments 
transmitted by a receiver to a transmitter. The present 
invention accomplishes this by providing sparse feedback 
from the receiver to the transmitter to indicate receipt of 
packets having headers to be used as reference header. More 
particularly, the present invention upon receipt in the 
receiver of a packet having a reference header, provides a 
feedback to the transmitter indicating receipt of the packet 
having the reference header. The receiver then waits a 

^ predetermined period of time before providing another feed- 
back in response to another packet having a reference 
header. This period of time allows for the feedback to 
traverse the link between the receiver and information 
indicating that the transmitter received the feedback to 
traverse the link between the transmitter an the receiver. 
Thus, the present invention makes for efficient use of the 
bandwidth of a network by providing a sparse number of 
feedbacks to a transmitter acknowledging receipt of a packet 
having, for example, a reference header. 

While the present invention has been described in detail 
and pictorially in the accompanying drawings it is not 
limited to such details since many changes and modifica- 
tions recognizable to those of ordinary skill in the art may be 
made to the invention without departing from the spirit and 
the scope thereof. 
We claim; 

1. In a system having a transmitter which transmits a 
plurality of packets to a receiver, each of the packets 
containing a header, a method of providing sparse feedback 
from the receiver to the transmitter indicating receipt of a 
packet having a header to be used as reference header, 
comprising: 

transmitting from the transmitter to the receiver a packet 
55 having a header to be used as a reference header; 

receiving in the receiver said packet having the reference 
header and in response providing feedback from the 
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receiver to the transmitter indicating receipt of said 6. The method according to claim 1, wherein said prede- 

packet having the reference header; and lermined period of time is a round trip time (RTT) repre- 

waiting a predetermined period of time before providing senting a time it takes for a packet to be transmitted from the 

another feedback in response to another packet having receiver to the transmitter and for the packet to be returned 
the reference header to permit receipt of information in 5 by the transmitter back to the receiver, 

the receiver indicating that the transmitter received said 7. The method according to claim 2, wherein said prede- 

feedback, termined period of time is a round trip time (RTT) repre- 

whercin said information received in the receiver includes senting a time it takes for a packet to be transmitted from the 

information transmitted by the transmitter indicating receiver to the transmitter and for the packet to be returned 

that the transmitter has altered its behavior based on by the transmitter back to the receiver, 

receipt of said feedback. 8. The method according to claim 3, wherein said prede- 

2. The method according to claim 1, wherein said infor- termined period of time is a round trip time (RTT) repre- 
mation transmitted by the transmitter is a packet having a senting a time it takes for a packet to be transmitted from the 
compressed header which is related to said reference header. receiver to the transmitter and for the packet to be retumed 

3. The method according to claim 2, wherein said refer- by the transmitter back to the receiver. 

ence header is a fiill header (FH) or a first order (FO) header. 9. The method according to claim 4, wherein said prede- 

4. The method according to claim 3, wherein said infor- termined period of time is a round trip time (RTT) repre- 
mation transmitted by the transmitter to the receiver indi- senting a time it takes for a packet to be transmitted from the 
eating its altered behavior is one of a FO header when said receiver to the transmitter and for the packet to be remmed 
reference header is a FH, and a second order (SO) header by the transmitter back to the receiver. 

when said reference header is said FH or said FO header. 10. The method according to claim 5, wherein said 

5. The method according to claim 4, wherein the altered predetermined period of time is a round trip time (RTT) 
behavior of the transmitter includes one of switching from a representing a time it takes for a packet to be transmitted 
FH state to a FO state and initiating transmission of packets from the receiver to the transmitter and for the packet to be 
each having a FO header, and switching from either a FH returned by the transmitter back to the receiver. 

state or an FO state to a SO state and initiating transmission 

of packets each having a SO header. * + * ♦ * 
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ABSTRACT 



A connection specific compression system is selectively 
implemented in connections having the greatest data 
redundancy and utilizes modularity in implementing 
data compression in a layered network commimication 
system. A data compression facility is interfaced in the 
layered system and intercepts data at a protocol layer 
prior to the data being packetized for transmission. A 
system acting as a compression host comprises a data 
packet switch driver which intercepts application data 
packets passing over layered network interfaces and 
routes selected client application data packets to an 
associated local compression process which has an inte- 
gral network protocol and which compresses the data 
stream in accordance with a selected compression algo- 
rithm. The compressed data passes through the system 
network protocol and the packet switch driver subse- 
quently sends the compressed data back into the com- 
munications stream through a network driver. The 
compressed data passes across the network communica- 
tion channel and is received by a decompression host 
having peer compression/decompression capabilities. 
The peer compression process decompresses the re- 
ceived data and sends it, via a second/decompression 
host resident packet switch driver, as though received 
from the network, into the decompression host system 
network protocol for connection with an application 
running on the second host. 

19 Claims, 9 Drawing Sheets 
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protocols for invocation on dissimilar interconnected 

METHOD AND APPARATUS FOR ADDING DATA systems, is illustrated and mapped in FIG. la to analo- 

COMPRESSION AND OTHER SERVICES IN A gous layers of the OSI model. 

. COMPUTER NETWORK TCP/IP is a four layer protocol suite which facili- 

5 tates the interconnection of two or more computer 

FIELD OF THE INVENTION systems on the same or different networks and in certain 

The present invention relates to data compression networks, such as the Internet, is a requirement for 

and in particular to data compression in the context of interoperability. The four layers, comprise two mde- 

networked computers. pendent protocols: TCP which can be used to access 

applications on other systems within a single network; 

BACKGROUND OF THE INVENTION jp ^j^j^h permits identification of source and desti- 

Systems are known which provide for connectivity in nation addresses for communication between systems 

and among networks of computerized equipment. Such on different networks. 

systems, ideally, must accommodate a proliferation of As illustrated in FIG. 2, application or process data 

cUfFerent network interfaces and hardware, as no single communicated via TCP/IP is "packetized" as it passes 

"standard" is adopted universally. down layers through the protocol suite. The original 

In order to permit computer systems to communi- process data first has an information block called a TCP 

cate, regardless of connection method or vendor- Header prefatorily appended thereto in a TCP layer, to 

specific hardware implemenUtion, or to permit differ- form a TCP packet. The TCP Header contains informa- 

ent networks to communicate or be "intemetworked", 20 ^^^^^ ^j^^^ traycls from point to point 

modularized/layered solutions have been proposed for ^.^jj^^y ^j^jj^^^ pj^y^g g^rors or getting lost. An IP 

the problems associated with interconnectivity. Layer- ^ repacketizes the TCP packet into an IP packet, by 

ing divides the task of mtercomiection and commumca- ^ jp ^^^^^ ^^^^^ ^^^^^ information 

tion mto pieces (layers), wherem each layer solves a ^^^^ j^^^ ^ destination node. The IP 

pieceof the problem or provides a parti^^ 25 b packetized, such as in ANSI/IEEE 

andismterfacedto adj^^^^ P J^^^^ ^ ^^^^^^^^ 

responsible for providing a service to ensure that the • . » • i a> * i /i t>^\ i. j a ««« 

communication is properly effected. Examples of some Lof cal Lmk Control (LLC) address header and a con- 

services provided by the various layers are error detec- ^ol header at an LLC layer, to an LLC Protocol 

tion. error recovery and routing among many commu- 30 Data Unit (LLCPDU). Tlie LLCPDU is "framed" for 

nication paths. All the layers in conjunction present the transmission by addition of a Media Access Control 

overall communication solution. Experience has shown Header and Trailer, to form a MAC Frame for commu- 

that modularizing in layers with well defined functional nication between two TCP/IP facilities, 

interfaces, divides and effectively reduces the complex- It is apparent that a considerable amount of "bag- 

ity of the connectivity problem and leads to a more 35 gage", in the form of headers and trailer, is added to 

flexible and extensible solution. data which is transmitted between facilities using a 

A model for describing the layers in a network has layered protocol suite, such as TCP/IP and other OSI 

been posited by the International Standards Organiza- modelled families. Many additional bits are added at the 

tion (ISO). The ISO open systems interconnection various layers and must be processed for ultimate trans- 

(OSI) model is a seven-layer model, illustrated in FIG, 40 mission across a communication channel at the physical 

1, which provides a standard for describing a network layer. At its destination, the transmitted frame must be 

and facilitating computer conMnunications. OSI and unpacketized according to embedded instructions and 

other layered computer network communications stan- passed upward throujgh the layered protocols to its 

dards are discussed in detail in Unix Network Program- receiving application or process. 

ming by W. Richard Stevens, and Handbook ofComput- 45 ^^j^g ^^^^ significant processing overhead asso- 

er-Communication Standards by William Stallmgs, dated with packetizing data for network and intemet- 

which are incorporated herein by reference. The OSI ^^^^ transmission, data itself may be redundant, such 

model defines the layers and units of mformation that ^j^^^ j.^^, ^^^^ associated with putting data and aU its 

pass along a network. As illustrated, data from an ajpph- ^010^0! suite baggage across the communication chan- 

cation or process runnmg on a first host (HOST A) 50 J^^j 

moves down the model network laye« to a Physical ^^^^^ communication chamiel is integral to a 

layer. Tlie Physical layer defines the physical connec- ^^^^^^^ . ^^^^^^^ 

tion which transmit raw bU^^^^ f^Tr^oT ^^a and protocol suite baggage on transmission costs 
channel to another host (HOST B) and up correspond- , *^ j . j « «7ixT 1 t. j- 1 

ing layers to a process rumiing thereon. OSI, while 55 can be measured in dollars. WAN 
defining a model or framework in which standards and Phone lines typically have relatively low fixed upper 
protocols can be developed at each layer, allows for a ^^'^ <^^^. transmission rates and are billed based on 
flexible approach for implementation of the model. ^^^^^^ time, packet count or bandwidth use. Thus, the 

Layered protocols and interfaces therebetween have extensive packetization and resultant bits that must be 
been defined, which provide specifications for commu- 60 transmitted mcrease connect time and dollar cost Addi- 
nication between a process or program being executed tionally, the numerous appended bits significantly in- 
on one computer's operating system and another pro- crease the possibility of transmission errors on less reli- 
cess running on another computer. Transmission Con- able lines. Where WAN links, such as analog leased 
trol Protocol/Internet Protocol (TCP/IP) are two pro- lines, and Dataphone Digital Services (DDS) are used, 
tocols that are part of a protocol suite or family of pro- 65 monthly or annual subscription fees recur and to a great 
tocols layered and designed to connect computer sys- extent are consumed by traffic comprising the transmis- 
tems that use different operating systems and network sion of redundant bits and protocol attributable header 
technologies. TCP/IP, which provides a common set of and trailer information. 
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Compression schemes and apparatus are known second/decompression host, the data packet switch 
which reduce the quantity of bits that must be transmit- driver establishes a connection between a chcnt apphca- 
ted across the communication channel. However, data tion on the compression host and a system network 
compressing modems, such as disclosed in U.S. Pal. No. protocol kernel interface (commonly caUed a socket) 
4,748,639, compress data streams after packctization for 5 and routes selected client application data packeU to an 
transmission over the communication channel. Signifi- associated local compression process which has an inte- 
cant additional hardware is required, in the form of a gral network protocol. The daU packets selected for 
compression modem and a decompression modem. The compression arc delivered to the compression process 
additional hardware, which translates into significantly which opens a second connection to the system net- 
increased system cost, requires frequency tables to 10 work protocol interface and compresses the data stream 
recodify and decodify or decompress characters in a in accordance with a selected compression algorithm, 
data stream in accordance with a compressed character Jhe compressed data passes through the system net- 
code. Such a compression scheme is not host resident, work protocol and the packet switch driver subse- 
does not take advantage of the modular/layered struc- quently sends the compressed data back into the com- 
ture of the network communication system and lacks 15 munications stream through a network driver. The 
the flexibility to reduce the number of packets and head- compressed data passes across the network communica- 
crs generated in the transmission of a particular data jj^n channel and is received by the decompression host 
stream. Further, because compression modems service having compression/decompression capabilities ac- 
multiple connections and daU that may come from one cording to the invention. 

or more systems, redundancy of daU tends to be ran- 20 jj^^ decompression host receives the compressed 

dom. It is appreciated that randomly redundant dau is through its network interface and delivers it to a 

more difficult to compress. compression process having its own complimen- 

Network bridge products are available that also have integral network protocol. The peer compression 

data compression facilities. However, much like com- process decompresses the received daU and sends it, via 

pression modems, bridges do not provide host resident 25 ^ second/decompression host resident packet switch 

end-to-end compression facilities. Bridges also do not ^^^^^^ ^ ^j^^^^jj received from the network, into the 

have the capability to reduce packet count. Like com- decompression host system network protocol for con- 

pression modems, bridge products are not connection ^^^.^^ ^ application running on the second host, 

specific and must process data from vanous connections ^^^^^^ embodiment, a host system having data 

which tend to provide data that IS randomly redundant 30 .j^^ according to the invention is used as a 

Thus data compression with bndge products may not transmissions of systems not having 

achieve optunal compression ratios compression according to the invention, which are 

Host resident compression is ^^^^^^^^^^^^^^^^ ^tined for another host having compression accord- 

tion programs that mcorporate compression algorithms. • * • ♦•^ or 

Howev.r.suchprogra™stypi<^lyrctricve.mefrom^ 35 '"^p^ ~invc„,i„„ ,„a-to^d en- 

mass storage dev.ce such|« ^^''^^^^^f'P^^^^'^t^^ hanced data transmission having daU compression that 

and retumit to the disk. J^IJ'?^^^^^^^^'''^!"'^ „ transparent to the user effected between at least two 

rctneved from the disk to be shipped through the net- *^ * j * j t^, ««^u*te 

work layers for transmission. In kddition to the signifi- hosts^ Reduction m daU ^^.^^^'^^^^^^^ 

cant additional overhead required for the disk storage 40 ^'^TT^^^!^ 2^L3tiLe 

and retrieval, such compression applications require Wide Area Network perfo^m^ and response Ume 

that process daU be effectively compiled as a Som- whib traffic is reduced to ^^^^fy^''^^^^ 

pressed data file and recompiled or decompressed at a bandwidth^ Compression accordmg to the mvennon 

destination facility. Such compression and decompres- can be used with vanous network interfaoes supported 

sion significantly delays the avaDability of data sub- 45 by the host because it o^rates mdependently of he 

jected to this process of daU transmission. Such decom- network physical layer. Bndg^ and routers on the 

pression programs, although host resident, are typically network will not affect, or be affected by. transmission 

not integrated with particular applications and must be of data serviced accordmg to the mvcnuon. 

invoked so that they are not transparent to the user. A compression management facility permits system 

50 manager mvocation and defmition of a configuration 

SUMMARY OF THE INVENTION fjc of paths or connections in the network, which are to 

The present invention is a connection specific com- be compressed. Parameters can be set and displayed 
pression system which U selectively-implemcnt^ in relating to data to be selected for compression. Statistics 
connections having the-greatest-dateliSjufflancy and can be compiled and logged, to track: number of pack- 
takes advanuge of mocluliritrMrMnplementing data 55 txs sent and received; number of connections serviced; 
compression in a layered network communication sys- number of connections open; compression ratio; and 
tern. A data compression faciUty isjntcrfa^ed^^ compression paths and mterfaces m use. 
layered system and i^^gpts^d^a^^at^a^ DESCRIPTION OF THE DRAWING 
prior-to^the'data~being packetiicd-if6r_trahsmission. 

Tkerifo«rf^^n?i^ctsjie^^ 60 The invention wUl be more fully understood from the 

headers and trailers need to be generated to transmit the following detailed description taken in conjunction 

compressed data. with the accompanying drawing in which: 

According to the invention, a system acting as a com- FIG. 1 is a diagrammatic view of an Open Systems 

pression host comprises a data packet switch driver Interconnection (OSI) model according to the prior art; 

which intercepts application data packets passing 65 FIG. 1^7 is a diagrammatic view of the OSI model of 

through layered network interfaces, prior to further FIG. 1 compared to a Transmission Control Protocol- 

packetization. When the system is acting as a compres- /Internet Protocol (TCP/IP) model according to the 

sion host and transmitting data to an application on a prior art; 
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FIG. 2 is a diagrammatic view of data packetized in paths, established via the management utility 26 and 

accordance with the TCP/IP model of FIG. la; maintained by the compression process 24 discussed 

FIG. 3 is a block diagram of an illustrative TCP/IP hereinafter. 'Hre^jacke^sv^^^ 

connection from a first host to a second host across a data packet-address fflpended^nrg^ ^ 

Wide Area Network, according to the prior art, with- 5 (^n mnes" if the d jtaEggd^^^ 

out data compression; pr^sion. If^e-paefcet!s>yitchTanveP22^e 

FIG. 4 is a block diagram of a two host end-to-end ' " ' 
connection having compression according to the inven- 
tion in a TCP/IP implementation; _ _ _ 

FIG. 4j is a block diagram of a host having compres- lO'^sef^t^Fdat^pji^t^m-^c^^ 

sion according to the invention in a TCP/IP implemen- hs ted'm ixon figur^^ 

tation; tnent-util itv iS, ar e^swi tched^o^^le^t^^ 

FIG. 5 is a flow chart of functions of a packet switch pc6cess-24. 
driver of FIG. 4a; Packets intercepted by the packet switch driver 22 

FIG. 6 is a block diagram of a compression process of 15 for compression are passed through a compression 

FIG. 4a; and process-packet switch driver interface 32 (FIG. €) and 

FIG. 7 is a block diagram of a system having com- received by internal TCP/IP layers 30 that are func- 

pression according to the invention implemented as a tionally interrelated with the compression process 24. 

gateway. and not part of the host TCP/IP 12 running under the 

nPTATi Pn nP^irPTPTTmsj operating system. The compression process 24. illus- 

DETAILED DESCRIPTION ^^.^^^^j pjQg ^ ^ functioning with the internal 

A host-to-host interconnection of two computers TCP/IP layers 30, performs TCP/IP input processing 
having 3i:CB/I£inetwork capabilities for conmiunicat- which assures the reliability of the data stream in the 
ing across a Wide Area Network, as illustrated in FIG. packets received from the packet switch driver 22. 
3, provides a suitable environment for discussion of the 25 A compression/decompression module 34 represents 
present invention. Without compression, such an inter- a service module which is modularly integrated with 
connection comprises an application 10 running under the internal TCP/IP layers 30 and communicates with 
an operating system on a first system, Host A, which the host TCP/IP 12 for transmitting data on the net- 
transfers data to a socket or interface of a TCP/IP work. The compression/decompression module/34 
protocol stack 12 comprising two layers, TCP and IP, 30 comprises a general purpose compression/decompres- 
of the four layers of a TCP/IP protocol suite for packe- sion algorithm, ^hid^i^nteffaced^toripermitr^differei^ 
tizing the data for transmission, as discussed hereinbe- cGinpi^ioS^SiOioaPlo-1)? A corn- 
fore. Fully TCP/IP packetized "datagrams" are deliv- pression/decompression module 34, in one example, is 
ered to a network interface driver, which effects further an implementation of a Lempel=Ziv^gQnthm~fpr=se» 
packetization, framing and transmission of the data on 35 qas?B^^ata=^mprcsSfbn, which is deselectable or 
the WAN medium. A network interface driver at the modularly removable to penDih scleetion^of^^a iterna- 
receiving host, Host B, strips and passes the datagrams, tive.alfio rithtnrknown;ffl the art, such as an LZW com- 
includiiig the data, to a Host B TCP/IP kernel where pression implementation or Huffman encoding. Data 
the data is de-packetized and a connection is accepted received by the compression process fromvthe packet 
and made to an application or process running thereon 40 switch driver 22 is compressed for tran^ssion by the 
which reads the data. compressio n/dec ompression module 34£in3acee£aSi^ 

Referring now to FIG. 4, a system 20 h^n^CIVlP^ wt^ss&^f^f^^^X^pS^^^ 

capabiites^^diidata-jsompreg ipn^ccor^ ' A compressi'^control module 36 in the compression 

vcnti on-.compr ises:ajfirstdlost. Host A, having a packet process 24, in conjunction with a management module 

switch driver 22 installed between the host TCP/IP 45 38 that is a compression process resident portion of the 

kernel 12 which receives data from the application or management utility 26, eflfect two phases in communica- 

process 10, and a network interface driver 28 that ef- tion of compressed data from the compression process 

fects a lower layer of packetization, framing and trans- 24 to a remote compression process 40 (FIG. 4), within 

mission of the data on the WAN. The packet switch remote Host B. 

driver 22 communicates with a local compression pro- 50 A flrst phase in communication of compressed data 
cess 24, which is itself in communication with the host between compression processes involves the negotia- 
TCP/IP kernel 12 and functions as described hereinaf- tion of connections. If it is determined by the switch 22 
ter. A management utility 26 oversees and facilitates that a request to connect to a remote application re- 
configuration of compression within the system 20, quires invocation of data compression, the local com- 
according to the invention. 55 pression process 24 that receives the diverted data de- 

When the application 10, such as one running on Host termines if a connection needs to be made to the remote 
A, seeks to communicate with a remote application 14, compression process 40 at the specified destination in- 
such as one running on Host B, a request and data are temet address. A connection table (not shown) within 
passed to the host TCP/IP layers 12 running in an oper- the local compression process maintains the status of 
ating system kernel. The packet switch driver 22, as 60 TCP/IP connections made or being attempted between 
illustrated in FIGS. 4, 4a and 5, receives all data travel- local and remote internet address/port pairs. The local 
ling to the network interfaces from an application^_^en compression process 24 attempts to connect to the re- 
packet^j witch~dri ver ':22~examin es"an"ju^^ mote compression process 40 internet address specified 
inftrce^telecteddStaJolrkpiifi^^ in the local application's connection request. If the local 
prggicmgprocjessng4, a ocordin g gorprg djetjermined::^^ compression process 24 does not have sufficient re- 

sources or resources available, such as free memory, an 

d>ata3is7selectea~for^6mpfession^ unused connection and/or does not support the selected 

ing-parame^ rs, such as network interface ^g^es and algorithm, the attempt is aborted and the connection 
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table modified accordingly. If a connection attempt sion/decomprcssion algorithm, back into the communi- 
fails, perhaps because the remote host is down or other- cation stream of the destination application, 
wise not available for connection, the local compression If the connection between the remote compression 
process maintains a decision table (hke the decision process and the destination application fails, a response 
table which the packet switch driver uses in detennin- 5 buffer is returned that is indicative f the error. When 
ing if a given application's data should be diverted for the local compression process gets the data buffer back 
compression), which is updated to indicate that connec- with the indicated faUure. it wUl effect closure of the 
tion packets destined for that internet address should TCP/IP connection and update the connection and 
not be diverted for compression. A timeout scheme and decision tables accordingly, so that the connection pro- 
retry mechanism may be implemented so that the re- 10 cccds normally. 

mote internet address may be tried at a later time, or the The management uulity 26 facilitates management 

compression process may choose to route uncom- and control of the configuration of compression p^^^^^ 

presUd dau over a normi connection. A system manager can define a configuraUon file 42 

A second phase in communication of compressed ^^ich is accessible to the "^^^^^^^^ ^^f^jfj^ 

data is the actual data transfer between the local and 15 compression proofs to ^Pf^fV j^;";^^^^ 

remote compression processes can proceed if the ^^T'^^^^'' '%*fn^^^^ 

TCP/IP connection is effected. The local compression °''T\'"^'^f"/JTf^^^^^^^ 

process 24 will send a buffer of data to the remote com- ^^er will mtercept P^^j^^^^^^^^^^ 

wdl contain application to application^ in^rdance with the TCP/IP addressing 

addi«smgmformation.mformatK^^ ^^^^^ ^^^^^^ ^ destination internet address, 

to be provided by the local and remote compression port, source internet address and source 

processes and information conccmmg the selected com- Unidirectional or bi-directional compression can 

pression algonthm and its use. The remote compre^ion ^ specified. Tlie configuration file is read upon initial- 

process receiving the data cxammes the vanous fields of .^^^^ hereinbefore defined compr«sion imple- 

information to determine if there is resident support for mentation 

the facilities requested. If the remote compression pro- Referring now to FIG. 7, the compression implemen- 

ccss can not support the dato. the connection will be ^^^^^ according to the invention can be effected as a 

aborted and the data will be returned to the local com- 3^ g^t^way implcmenUtion in a local area network having 
pression process with a response header indicative of ^ plurality of processors, or gateway clients, that do not 

the remote process facilities and the stotus of the con- yi&vt such a compression implementation installed 

ncction. thereon. One host 50 having compression according to 

The remote compression process, determining that jjj^ invention implemented thereon acts as a gateway 

there is support for the data transmission, tries to estab- 35 ^ plurality of gateway clients 52 on the network to 

lish a connection to the remote application indicated by facQitatc communication with a remote host 54 having 

the destination address in the header. The remote coni- ^^^^^ ^ compression facility. The gateway clients 52 

pression process establishes the connection to the desti- n^j^ ^ known to the compression host 50, such as by 

nation application, through the remote host packet establishing an indicative field in the configuration file, 

switch driver 44, and the remote host TCP/IP 42. This 40 ^ ^y^i the gateway clients 52 can be serviced while 

is done in such a way that the address/port may be other systems 56 on the network are precluded from 

modified to present the appearance that the local appli- similar services as described hereinbefore, 

cation 10 was connected directly to the destination jjje compression/decompression module 34 modu- 

application in the remote Host B, without the interven- i^rly integrated in the compression process 24 (FIG. 6) 

ing compression processes. This avoids the invalidation 45 can be replaced or supplemented with additional modu- 

of the transmission by applications which selectively lar facilities to provide other services in the communica- 

vcrify incoming port numbers for validity. tion stream between layers of a given protocol stack. 

When the connection to the destination application is Services such as encryption/decryption could be made 
established, the remote compression process returns a available to networked and intemetworkcd computing 
response data buffer to the local compression process 50 machinery, according to the invention. 
40, which will indicate that the selected compression Although the invention as disclosed hereinbefore 
algorithm was accepted, and the sutus of the connec- describes data compression in the context of networks 
tion. When the local compression process 24 gets the according to TCP/IP, it can be appreciated that data 
response data buffer back from the remote compression compression can be implemented according to the in- 
process 40, it effects updating of the compression pro- 33 vention between analogous layers in protocol suites 
cess connection and decision tables and the packet other than TCP/IP, such as DECNET and OSI stan- 
switch driver connection and decision tables. The infor- dard protocol suites and the like, 
mation regarding address and selected compression While data compression according to the invention is 
algorithm are stored, preferably in the connection table, described in the context of compression for transmission 
for use on the affected connection. The connection is 60 on a wide area network, it will be appreciated that 
completed locally, in the remote Host B. Host A surts compression according to the invention is applicable in 
compressing and transmitting data, while in Host B, the the context of local area networks. Especially with the 
remote compression process decompresses transmitted trend in increased processor speeds which may result in 
data into the original data stream, performs TCP/IP compression processing speeds in excess of LAN trans- 
processing in its internal TCP/IP to rebuild the data 65 mission speeds. 

into packets and writes the data to the packet switch Although selection of data for compression is ef- 

driver 44. The packet switch driver 44 injects the data, fecied hereinbefore in accordance with an address in 

decompressed in accordance with the selected compres- the header, other daU fields can be csublished and 
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other criteria used for selection of data for provision of 
services as described. 

One of ordinary skill in the art will appreciate that the 
invention described hereinbefore can be implemented in 
software, hardware or a combination thereof. 5 

Although the invention has been shown and de- 
scribed with respect to an exemplary embodiment 
thereof, various other changes, omissions and additions 
in the form and detail thereof may be made therein 
without departing from the spirit and scope of the in- 10 
vention. 

What is claimed is: 

1. An apparatus for integrating services between pro- 
tocol layers in a computer system having layered net- 
work protocols, comprising: IS 

a first network layer having a first interface, and a 
second interface and operating according to a first 
protocol, and a second network layer having a fu^t 
interface, and a second interface and operating 
according to a second protocol; 20 

a switch driver responsive to said second interface of 
said first layer that receives a plurality of signal 
groups therefrom, said switch driver being con- 
figurable for routing at least some of said plurality 
of signal groups through at least one of a first path 25 
and a second path to said first interface of said 
second layer; and 

at least one service module responsive to said switch 
driver for receiving at least some of said plurality 
of signal groups through said first path and that 30 
performs an operation on said at least some of said 
plurality of signal groups from said first path to 
form a plurality of modified signal groups, 

wherein said at least one service module transmits 
said plurality of modified signal groups to said first 35 
interface of said first layer and said switch driver 
receives said plurality of modified signal groups. 

2. The apparatus of claim 1 wherein said switch 
driver is selectively configurable in accordance with at 
least one set of predetermined criteria. 40 

3. The apparatus of claim 2 wherein said at least one 
set of predetermined criteria is tested by comparing 
selected signals with a portion of signals of each of said 
plurality of signal groups. 

4. The apparatus of claim 1 wherein said at least one 45 
service module comprises a compression processor and 
said operation performed on said at least some of said 
plurality of signal groups is data compression. 

5. The apparatus of claim 1 wherein said at least one 
service module comprises a decompression processor 50 
and said operation performed on said at least some of 
said plurality of signal groups is data decompression. 

6. The apparatus of claim 1 wherein said at least one 
service module operates according to a protocol com- 
patible with said first protocol of said first layer. 55 

7. The apparatus of claim 1 wherein said switch 
driver receives said plurality of modified signal groups 
for routing to said first interface of said second layer. 
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8. The apparatus of claim 1 wherein said at least one 
service module comprises an encryption processor and 
said operation performed on said at least some of said 
plurality of signal groups is data encryption. 

9. The apparatus of claim 1 wherein said at least one 
service module comprises a decryption processor and 
said operation performed on said at least some of said 
plurality of signal groups is data decryption. 

10. Tlie apparatus of claim 1 wherein said protocol of 
said first layer requires disassembly of a data stream and 
assembly of said at least some of said plurality of signal 
groups therefrom and said at least one service module 
receives said at least some of said plurality of signal 
groups and reassembles said data stream. 

11. The apparatus of claim 1 wherein said switch 
driver includes at least one set of predetermined criteria 
for determining said at least some of said plurality of 
signal groups for routing to said at least one service 
module. 

12. The apparatus of claim 1 wherein said at least one 
service module includes at least one set of predeter- 
mined criteria for determining said at least some of said 
plurality of signal groups for routing to said at least one 
service module. 

13. The apparatus of claim 1 wherein selected signals 
are stored in an accessible and modifiable configuration 
file. 

14. The apparatus of claim 1 further comprising a 
path to pass a second plurality of signal groups from 
said first interface of said second layer to said second 
interface of said first layer and from said first interface 
of said first layer to said service module. 

15. A method for providing a service between proto- 
col layers in a computer system having layered network 
protocols, said method comprising the steps of: 

intercepting a first plurality of signal groups travel- 
ling along a layered network protocol stack at a 
first layer interface; 

comparing a portion of each of said fu^t plurality of 
signal groups with a predetermined set of signal 
groups to determine selected signal groups for 
performing an operation thereon to provide said 
service; 

routing said selected signal groups to a service mod- 
ule; 

performing said operation on said selected signal 

groups to provide said service; and 
routing said selected signal groups to a second layer 

interface. 

16. The method of claim 15 wherein said operation is 
data compression. 

17. The method of claim 15 wherein said operation is 
data decompression. 

18. The method of claim 15 wherein said operation is 
data encryption. 

19. The method of claim 15 wherein said operation is 
data decryption. 

***** 



65 



06/20/2003, EAST Version: 1.03.0002 



UNITED STATES PATENT AND TRADEMARK OFHCE 



CERTIFICATE OF CORRECTION 



PATENT NO. 



5,307,413 



DATED 



April 26, 1994 
Philip C« Denzer 



INVENTOR(S) 



It is certified that error appears in the above-indentified patent and that said Letters Patent is hereby 
corrected as shown below: 

Column 3, line 5, "streams after" should read 
- -streams after - - . 

Column 7, line 16, "processes can" should read --processes 
which can- - , ' 



Signed and Sealed this 
Third Day of January, 1995 



Attest: 




BRUCE LEHMAN 



Attesting Officer 



Commissioner of Patents and Trademarks 



06/20/2003, EAST version: 1.03.0002 



